Date: Mon, 14 Apr 1997 06:17:45 -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.970414052100.9118A-100000@phobos.illtel.denver.co.us> In-Reply-To: <199704141215.HAA01021@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Apr 1997, John S. Dyson wrote: > (This is getting argumentative, IMO, if you want to run Linux -- go > do that. Time will tell, and it is best not to insult other's work. I am using both Linux and FreeBSD and really don't need anyone's recommendations for both. > FreeBSD wouldn't be growing so quickly, getting so many migrations > or doing so well if we were totally screwed up. :-)). If all development was screwed up there will be no result at all. [skipped] > > distribution that had xterm using wtmp format from one version and the > > rest of system from another. > > > Of course, FreeBSD has all of the above also, even though you are trying > to speak of the quality of all of the Linux distributions, Quality differs. But all of them are consistent and based on the same kernel, libc and base utilities. Slackware has BSD-like init scripts and Red Hat has SysV ones (the same SysV-like init itself in both), utilities differ and packaging systems are completely different -- that doesn't make different OS. > and I only need > to speak of one. So what? > I think that I can be assured of what I am saying. > Then they haven't had to change the wtmp format because of increasing > the size of login id's. Simple, but unfortunate... That change was > made as a result of user demands. Change is ok, inconsistent "quality-controlled" distribution isn't. > > > 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. > > > Then why RPM it? :-). I am not sure that you know everything that > goes on. RPMs 1. often maintained by authors, 2. never contain patches for original sources, 3. don't FTP sources, 4. support dependencies, 5. part of Red Hat distribution. [skipped] > I don't understand what you are saying... I think what you are saying > now is bogus. I can say the same thing about RPMs. The ports > mechanism DOESN'T force you to install things automatically, you can install a > port or not. This is getting very bogus. Install or not. Nice. Linux users at least maintain distribution sites with original sources, be it something written specifically for Linux, ported and maintained by author or ported (and maintained) by someone else, but at least it's clear what was posted when and who is maintaining that and where (lsm entries). It may look completely chaotic and "unmanageable", but it works. Distributions allow more "controlled" way to get the same software, and they are maintained by their vendors not based on blindly copied "ports collection" but on original authors sources. Commercial vendors, obviously, like RPM system better, too. > > > 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. > > > There are also commercial distributions on the FreeBSD disks... The question > that I have is are all of the Linux distributors who might be sending > off Kermit making an agreement with the authors? That license ain't > GPL!!! That is the only reason that we don't have Kermit on our distribution, > we really do look at licensing terms. Linux distributions aren't GPL'ed, and I believe that distributors don't violate licenses. This is an advantage of having more than one "allowed" distribution -- commercial vendors can include their products on some. [skipped] > > by -current I mean -current, not 2.2.x. And stability of 2.2 could be > > better, too. > > > This argument also makes no sense. If you don't want to do kernel or forward > looking userland development then don't use -current. You are saying that > if you want something fixed, you must use -current -- that is simply wrong. > 2.2.X is going to be well supported for quite a while... For now it has problems that aren't fixed anywhere but in -current. Or not fixed anywhere. And upgrades are "everything or nothing". [skipped] > > new libraries and allow upgrades with at least less pain that FreeBSD > > causes. Manual upgrades within major version number are mostly painless. > > > Sorry, but finding the right Linux shared lib is a right of passage to > install new software. That is common knowlege, and my experience. If some _really_ old version survived major kernel upgrade - yes. But it isn't supposed to. [skipped] > > > 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. > > > Well, you are supporting my position on Linux shared lib coherency. Thanks for > providing an anecdotal example :-). It's an example of broken program that still works because only malloc was broken. Where have they found original library, and did that binary ever work with java at Netscape is still a mystery for me. > > 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). > > > I am not either. I am talking about having to forage around for the > "right" shared lib. You have to be ready to do that on Linux. Why I never had that problem? [skipped] > Sorry, but core is 17 people, and the committers are currently approx > 70. Too bad, but it does work and we are organized. Chaos doesn't make a > release. I am sure that Red Hat spends lots of time trying to produce a > release, and so does Debian, and so does Slackware, ad nauseum. Do you think > that they will all make the same choices??? NOT!!! If they do, then > why so many versions with the same Linux kernel? I don't understand it. Because different vendors make them. Or you mean that simultaneously released distributions have _different_ kernel versions? > Please refer to > the vendors who say: "This code is supported under VX.Y of the > frobnotz Linux distribution with the VA.B of the Linux kernel" or somesuch. But vendors for some reason produce software for Linux. And it works on distributions other than one, that software was originally shipped with, too. Why? Maybe, differences between distributions are umm... exaggerated? > > > 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. > > > FreeBSD updates kernel/libraries/binaries simultaneously :-). Of course, > sometimes on Linux or using Linux binaries on FreeBSD you have to forage > around for the right shared libs :-). FreeBSD's security record isn't very > bad, Currently the same as Linux one. With all "uncontrolled" things, I remember how I applied buffer-overflow patches to mostly the same things on both systems. > and we have alot of users who demand security. I don't know how your > statement compares the two OSes -- FreeBSD does all of the above. Of > course, how compatible is the binary environment between two different > Linux kernel based distributions? There are alot of combinations to > compare. Kernel/libc combination is the same -- they are "controlled" at least as good as FreeBSD ones. Packages, maintained "outside" as a whole, like XF86, are included simultaneously, too. init scripts, cron/bind/sendmail/lpd/perl and set of different Emacs versions differ though. [skipped] > Sorry, but an inside group of 17/70 people isn't too awful small. Of course, > an inside group of 1 kernel owner IS an inside group. We do have a > checks and balances system and organization which works very well. Of > course, a kernel doesn't make an OS -- it is mostly a scaffolding for > programs. So, Linux has an interesting situation -- a kernel that is > controlled by one person under a commercially undesirable license, and > LOTS and LOTS of distributions with different configurations. > FreeBSD has a single kernel with a single distribution. We do have > different releases that we distinguish, but the situation is simple > for vendors. > > So much for branding. How 4front-tech makes OSS without trouble from such horrible thing as GPL'ed kernel... -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970414052100.9118A-100000>