Re: Compare Linux and Freebsd Redux
From: John S. Dyson (toor_at_iquest.net)
Date: 05/30/04
- Next message: John S. Dyson: "Re: Compare Linux and Freebsd Redux"
- Previous message: John S. Dyson: "Re: Compare Linux and Freebsd Redux"
- In reply to: Alan Hicks: "Re: Compare Linux and Freebsd Redux"
- Next in thread: Tim Hammerquist: "Re: Compare Linux and Freebsd Redux"
- Reply: Tim Hammerquist: "Re: Compare Linux and Freebsd Redux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 30 May 2004 06:35:58 +0000 (UTC)
In article <40b93b0b$1_2@127.0.0.1>,
Alan Hicks <alan@lizella.netWORK> writes:
> In comp.unix.bsd.freebsd.misc, John S. Dyson dared to utter,
>> Perhaps the most unsettling 'misinformation' about the FreeBSD vs.
>> Linux situation was the spin that Linux was somehow more 'open',
>> yet up until recently, ONLY ONE developer could directly modify
>> the official Linux tree...
>
> How many developers can modify the official linux tree is not a real
> good determination of which is more "open" (as if one could easily
> quantify this quality). While there may be only one official linux
> tree, there are dozens if not hundreds of unofficial ones.
>
Forks of BSD software are also easily done. There is absolutely
NOTHING about the BSDL that stops the forks. Perhaps the biggest
reason for the relative lack of need for 'forking' or building
your own distribution is that the FreeBSD distribution is/was already
very coherent. The developer feeling that 'I can do it better'
would have been a very serious challenge, even in the early days
of bona-fide FreeBSD. The FreeBSD effort itself (not a distribution,
but the actual FreeBSD project itself) was very involved in dealing
with the full integration of a coherent OS.
Even the very early pre-386BSD code that I played with, came
as an essentially complete and integrated system (even though
it was as buggy as hell.) That bugginess was the ONLY motivation
that I had to 'do it better', because the BSD OS wasn't really
perceivable as 'piecemeal.' Maybe that was a reflexive behavior
to rebel against the typical software vendor behavior of
nickle and diming the customer to death...
>
> Most large
> linux distributions have their own kernel trees.
>
Are those kernel trees fully available to ANYONE, including
people outside of the userbase? FreeBSD's tree has been
available for years. The major availability glitch in the FreeBSD tree
was from the Net/2 legal problem.
>
> Comercial software
> vendors like netraverse (Win4Lin) maintain their own kernel tree. I'm
> sure NVIDIA maintains their own internal kernel tree for buidling their
> proprietary modules, etc.
>
Those examples (including the Linux examples) would certainly be for
software that has a MUCH MUCH more closed development than FreeBSD...
>
> Arguments over whom is "more free" than whom are IMO inane and not very
> productive. It can pretty much all be summed down to this:
>
Remember -- early on, it was the Linux advocacy who were always talking
about their 'open' development, when in reality, the kernel source tree
(which was the only real common denominator of Linux) wasn't modifyable
by anyone except for Linus. For FreeBSD, the
commonly available, fully integrated tree history is essentially
100% available, with full commit history. Perhaps the strongest
argument for Linux development being 'open' is that people would
cobble together their system from numerous pieces all over the
net -- while FreeBSD was supplied as a coherent and source controlled
entity.
>
> The BSD licensed code is "more free" in the sense that there are fewer
> restrictions.
> The GPL licenses code is "more free" in the sense that there is a legal
> requirement to continue distributing the source code and any
> enhancements some one makes should they distribute any portion of the
> software in any form.
>
Neither license guarantees that software will be distributed, and
the major difference (when all is said and done) is that the
GPL add-on developers work product is pre-ordained to be distributed
to those who receive binaries. The decision to release the
work product source code upon distribution of binaries is
finalized when the decision to use GPLed codebase. In the case
of BSDLed code, the decision to release the potentially expensive
add-on code can be deferred. This exact senerio has even happened
publically (e.g. by Kirk) for complex piece of software, yet there
was still a strong motivation (to get the common support) for Kirk
to distribute his VERY HARD EARNED workproduct.
When worrying about source distribution, all too often the advocates
forget about the spectre of the various net-support mechanisms. In
many cases, this is certainly an adequate counterbalance against the
tendancy to resist releasing a very expensive-to-develop work product.
>
> Just use whichever you want, and don't worry so damn much about ideals.
>
I agree -- except, it is VERY IMPORTANT that the choice be a
fully INFORMED choice.
>
>> Maybe that perception was persistent because FreeBSD as an OS has been a
>> fairly coherent development, while Linux (the concept, not just the
>> OS kernel) had variously been built from numerous constituents by
>> numerous groups of people.
>
> Well, that's not entirely true. Many things that are included in
> FreeBSD weren't developed by the BSD guys
>
That isn't want I am saying -- again:
FreeBSD has been a fairly coherent and complete development (whether
or not the 'development' is simple integration or new development.)
The 'flavor of the month' hasn't really needed to manifest, but
when there has been a SIGNIFICANT need for a fork, then that fork
had been created. Where the FreeBSD CVS tree has essentially been
available for everyone to see (including for all of the tools),
that kind of facility hasn't normally been available for Linux
(either the kernel or many of the distributions, until very recently.)
Linux desperately needed additional integration to become a real
OS, while FreeBSD was already a fairly coherent development project,
including a packaged development environment.
A simple example of the Linux integration issue: think about the
mix and match shared libraries issue (and finding the right mix
to support a specific pre-compiled application.) Each linux vendor
creates a different mix. On FreeBSD, the environment fully
specifies the environment, and each of the released versions
of FreeBSD almost fully supports reverse compatibility (where
the released libraries are mostly máde available for the
compatibility.) To support all of the numerous mix and match
combinations of shared libs for reverse compatibility amongst
all Linux systems would be 'interesting', to say the least.
t
>
> Grand-standing and petty
> arguments about who is "right" and who is "wrong" don't really help
> anyone or anything.
>
Perhaps it would be a good idea to avoid being prejudiced by
an assumption that there is 'grandstanding.' Please refer to
'Linux', and the fact that designation (even with a version number)
doesn't specify a C compiler. Refer to FreeBSD V1.1.5 (for example),
and you'll find an entire OS environment. For fun, think about
Linux V1.32 (or somesuch) -- that is only part of an OS, and
lots more needs to be integrated before you have a useful OS.
The reason to create a fork from a BSD is to create a substantially
different OS with very different features. Many of the various
Linux versions are mostly different mixes of install tools, ports
packages and/or compilers, etc. A different BSD fork will mostly
result from a very different set of goals (e.g. More machine
ports, optimized architectural support, advanced security, etc.)
John
- Next message: John S. Dyson: "Re: Compare Linux and Freebsd Redux"
- Previous message: John S. Dyson: "Re: Compare Linux and Freebsd Redux"
- In reply to: Alan Hicks: "Re: Compare Linux and Freebsd Redux"
- Next in thread: Tim Hammerquist: "Re: Compare Linux and Freebsd Redux"
- Reply: Tim Hammerquist: "Re: Compare Linux and Freebsd Redux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
