Date: Mon, 14 Apr 1997 08:52:58 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: abelits@phobos.illtel.denver.co.us Cc: toor@dyson.iquest.net, jbryant@tfs.net, dennis@etinc.com, freebsd-hackers@freebsd.org Subject: Re: Commercial vendors registry Message-ID: <199704141352.IAA01229@dyson.iquest.net> In-Reply-To: <Pine.LNX.3.95.970414052100.9118A-100000@phobos.illtel.denver.co.us> from Alex Belits at "Apr 14, 97 06:17:45 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > If all development was screwed up there will be no result at all. > But it isn't, so this line of argument doesn't mean anything. > > > 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. > To me, an OS isn't a kernel. A kernel is a smallish but critical part of an OS. > > 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. > Well, so what is wrong? I haven't had any trouble with XFree86 V3.2 or V3.2A (and I am running a -current kernel.) Also, I am running a terrible mishmash of various utilities of questional vintage (geesh, I ran FreeBSD V1.1/386BSD binaries will into the 2.0 timeframes.) Note that those were almost TOTALLY different kernels. Of course, I think that we can still run many Linux binaries (without any filesystem size/ shape restrictions) from that vintage also. > > 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. > Oh, ONE of the Linux kernel based OS distributions? Which ones support it, and which ones don't? > > 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. > I am saying that Kermit isn't GPL'ed and we have looked into redistributing it, thereby abiding by the Copyright/license terms, to no avail. > > For now it has problems that aren't fixed anywhere but in -current. Or > not fixed anywhere. And upgrades are "everything or nothing". > Please send-pr. 2.2 isn't that different from -current that problems can't be fixed easily. BTW, I regularly bring in a new kernel or specific userland pieces with little or no trouble. There is a difference between upgrade and release... And it is good on FreeBSD that you CAN have access to every version of every program for the cost of maintaining a fairly low overhead (if you are really in business), CVS tree. > > > 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. > Nor is it really a problem on released versions of FreeBSD. It still is a mix and match user-version control game on Linux. That is an obvious management issue. > > 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. > Again, it is an example of an interesting behavior, that the blind users of Linux (like me) who have to deal with the problem by foraging around for libraries. > > > 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? > Userlands are different, and a kernel doesn't an OS make :-). > > > 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? > Likewise, the binaries often work well with FreeBSD -- so the alleged insufficiency of FreeBSD with respect to Linux might be bogus? FreeBSD might run Linux binaries better than some versions of Linux kernels. Again, the issue comes down mimicking or dealing with the differing userlands, given the same kernel versions. Of course, kernel versions are not always the same -- so you have different "features." > > > 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. > So our development doesn't appear to break anything with respect to Linux. There is no proof of any points here. All this demonstrates is that there is an emphasis that appeared at roughly the same time in both some of the Linux distributions (of course, which ones have done the fixes?) and FreeBSD. Each also responds differently to threats (e.g. ping-of-death.) > > 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. > Which distributions, again? What distinguishes the distributions, and why are they so fragmented? What is the reason for so many versions? Can't they "just get along :-)". > > How 4front-tech makes OSS without trouble from such horrible thing > as GPL'ed kernel... > They are adding only a driver. Even though the kernel was originally GPLed, there was an after the fact exclusion of certain interfaces that allowed something like LGPL or other, more free and liberal terms to be enforced instead. The Linux kernel appears to have a mishmash of both GPL, LGPL, and free. These cause problems (especially mashed together) in certain situations (in which I am interested.) John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704141352.IAA01229>