Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Apr 1997 01:34:35 -0700 (PDT)
From:      Alex Belits <abelits@phobos.illtel.denver.co.us>
To:        "John S. Dyson" <toor@dyson.iquest.net>
Cc:        jbryant@tfs.net, dennis@etinc.com, freebsd-hackers@freebsd.org
Subject:   Re: Commercial vendors registry
Message-ID:  <Pine.LNX.3.95.970414000227.6395B-100000@phobos.illtel.denver.co.us>
In-Reply-To: <199704140653.BAA00534@dyson.iquest.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Apr 1997, John S. Dyson wrote:

> > and not fall apart instantly, distribution that supports upgrades
> > that could be done by user with minimal knowledge about OS internals
> >
> You mean the kernel of the week syndrome?

  No, "normal" Linux kernel upgrades don't need any mechanism because
major changes that affect programs/libc are rare (like ELF introduction 
or 1.2 -> 2.0 for normal user). When necessary to upgrade kernel to
version that affects installed user-space software it can be done
consistently either from source distributions directly or using packages
that are maintained by distributions vendors.  But I'm talking about
upgrades outside of kernel, and to do that one doesn't need to
replace/recompile half of his system to update libc or apply security fix
-- either using original sources or packages.

> > attractive for commercial vendors than FreeBSD with its closed-group
> > attitude.
> >
> Please contribute -- we aren't closed.  There is the issue of having
> quality control or not.  We choose the former.

  With so many things under that quality control it looks inefficient on
ones that really need it. In Linux most important packages that are
present in all distributions, are quality-controlled by definitely
knowledgeable people, who handle them. Other things are handled by
distribution vendors. Sorry to mention it, I have yet to see Linux
distribution that had xterm using wtmp format from one version and the
rest of system from another.

> > Example from "noncommercial" world: the idea of "ports" that
> > don't have to be supported by actual author/maintainer of a program but
> > can include "FreeBSD-specific" patch (most likely to some ancient version)
> > and doomed to instantly become outdated without original author's support
> > vs. Linux users tradition of using author's sources that are definitely
> > supported directly or Red Hat's rpm system that has its flaws but makes it
> > way harder for knowledgeable user to shoot himself in the foot.
> >
> Actually, I find alot of #ifdef FreeBSD and configure's that work directly
> with FreeBSD.  Much software works directly out of the box directly from
> the vendor/developer.

  Then why "port" it? And even if it doesn't why not to send those
"patches" to the original author? Will he support them worse? I don't
think, he will answer "I won't support FreeBSD, maintain patches to my
program yourself". At least, I can't imagine myself saying that.

>  You have the option of using the ports collection
> so that you have fewer problems or want to install directly out-of-the-box.

  This is not what I've seen. It installs things automatically. But I
never can be sure is the installed version even maintained now, not to
mention, is it the latest, or does the author support his own freebsd
port.

> Note also that the CDROM contains the apps that can be freely redistributed
> (unlike certain Zmodem or Kermit distributions.)

  Linux distributions contain commercial software if the distribution
vendor supports that. It's better for product vendor (distribution vendor
makes sure that distribution is consistent), distribution vendor
(obviously, money) and user (much cheaper than mail-order the same
thing, and there is an option to get the same or different distribution
without those commercial things if he doesn't need them). Of course, that
doesn't apply to extremely expensive products.

> >   Both Linux and FreeBSD change fast, although FreeBSD comes in one
> > monolithic distribution, and any attempt to get something fixed throws
> > user into -CURRENT (no pun intended but it seems appropriate) with all its
> > instability and experiments around.
> >
> Not true, 2.2.X is a new released codebase.  It isn't -current. Things get
> fixed in the 2.2.X base.  I wouldn't be suprised if 2.1.X is also still being
> supported for existing apps, on an as needed basis. 

  by -current I mean -current, not 2.2.x. And stability of 2.2 could be
better, too.

> BTW, -current isn't
> always stable -- and end users should use it only for experimentation,
> or they should support it entirely themselves.  Luckily, you can always
> check out a system source tree for any point in history (or release) with
> the CVS tree (which is publically available -- and you can have your own,
> local copy.)  That enables people to support themselves when running
> -current more easily (when absolutely needed.)  BTW, I have absolutely
> no trouble maintaining a CVS tree on my machine at home with a 28.8K
> modem.  There are various distribution mechanisms for the FreeBSD CVS
> tree, and you can choose the one that works best for you.

  Yes -- if you want to always keep up with OS development. Some people
like that, but most of them prefer to have something stable and do minimal
upgrades for functionality/security fixes, hardware changes and major OS
improvements.

> > If vendors that now support Linux had
> > to switch to 2.1.x kernel just to keep with library changes I believe,
> > they had used OpenNT by now.
> > 
> What about the users who have problems with the shared-libs of the
> week problem?

  No such problem. In Linux shared libraries change rarely, and
incompatible changes happen extremely rarely. Distributions are built with
new libraries and allow upgrades with at least less pain that FreeBSD
causes. Manual upgrades within major version number are mostly painless.

>  Which version of Netscape

Formally, Netscape Navigator Linux binary in form that is distributed at
Netscape FTP site is incompatible with all currently distributed Linux
libc versions. Netscape made horrible code that depends on malloc
implementation, and since it seems to be deaf to bugreports, netscape in
Linux is now running from the shell script that LD_PRELOAD's gnumalloc.
Everything else works fine even though Netscape binary definitely wasn't
built with the same libc version.

> /Staroffice, etc. with which
> shared-libs?  The only time that I have problems mixing/matching shared
> libs is when running Linux apps on FreeBSD or Linux apps on Linux.

  If you take programs in binaries and just copy them -- yes, you will
have that problem if program depends on things that changed. But those
programs mostly are distributed in sources. Again, I'm not talking about
major version number or features that never were announced as working in
"mainstream" distribution (such as mt-safe libc).

> >   FreeBSD technically is a nice OS. Organization of its development and
> > distribution looks umm... unhealthy.
> > 
> You mean a central group of people who are trying to maintain quality and
> branding (FreeBSD)?

  The way how it's done is a problem. "Ports" make things worse (don't
tell me that "ported" program has better quality than one, maintained by
the author). People are trying to be everything, and it's impossible.

>   Or a bunch of distributions with a bunch of different
> combinations of shared libs and apps (and kernel versions, Linux)?

  Linux is more tolerant to versions changes of components because its
design assumes that things should remain compatible. It not always
allows fast improvement in the code but encourages upgrades when they are
necessary (ex: security fixes). And all distributions that I know, update
kernel/libraries simultaneously.

>  I prefer
> a coherent development path/group.  It is pretty good that we have
> 70+- committers that can modify the tree directly, and don't have chaos.
> In fact, we are pretty well organized.

  "Organized" isn't always "good". And "you" are "organized" inside group
-- others just see that things randomly change without announce or
explanation. For commercial vendor it's worse, or at least, scarier.
M$ can afford doing random changes here and there -- but it 1. often does
that to gain advantage over other software companies, so its goal is
directly opposite to FreeBSD and Linux, 2. sends to developers those CDs
with suspiciously-looking logo and something more comprehendable than
-current sources on them.

--
Alex





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970414000227.6395B-100000>