Date: Mon, 14 Apr 1997 07:15:42 -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: <199704141215.HAA01021@dyson.iquest.net> In-Reply-To: <Pine.LNX.3.95.970414000227.6395B-100000@phobos.illtel.denver.co.us> from Alex Belits at "Apr 14, 97 01:34:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
(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. FreeBSD wouldn't be growing so quickly, getting so many migrations or doing so well if we were totally screwed up. :-)). > > > > 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. > 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, and I only need to speak of one. 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. > > > 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. > > 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. > 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. > > 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. > > > > 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. > 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... > > 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. > Then don't use -current. Use the supported 2.2.X/2.1.X releases. > > > 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. > Sorry, but finding the right Linux shared lib is a right of passage to install new software. That is common knowlege, and my experience. All it takes is time to forage around for the shared lib, download it and install it :-). If you run a release on FreeBSD, we also support previous shared libs and Linux binaries. Of course, given what you want, DON'T RUN -CURRENT. There are individuals, medium sized companies, and very large companies with large installations who have no problems running -current... That simply requires that they support their own pseudo releases. However, if you want to run as an end-user only, and don't want to support anything, then DON'T RUN -CURRENT. There has been no release engineering done on the raw -current code. We do -current snapshots once in a while, and those are not meant as end user releases. > > 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 :-). > > 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. > > > 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. > 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? 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. > > 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, 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. > > > 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. > 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. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704141215.HAA01021>