From owner-freebsd-hackers Mon Apr 14 01:33:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA26079 for hackers-outgoing; Mon, 14 Apr 1997 01:33:00 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA26074 for ; Mon, 14 Apr 1997 01:32:53 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id BAA07889; Mon, 14 Apr 1997 01:34:35 -0700 Date: Mon, 14 Apr 1997 01:34:35 -0700 (PDT) From: Alex Belits Reply-To: Alex Belits To: "John S. Dyson" cc: jbryant@tfs.net, dennis@etinc.com, freebsd-hackers@freebsd.org Subject: Re: Commercial vendors registry In-Reply-To: <199704140653.BAA00534@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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