Material to perhaps base a leaflet on ? From owner-freebsd-advocacy_ERASE@freebsd.org Tue Oct 29 16:23:12 2002 Date: Tue, 29 Oct 2002 07:04:11 -0600 (CST) Message-Id: <200210291304.g9TD4Bf02105@sheol.localdomain> Mime-Version: 1.0 References: <200210281311.34328.djohnson_acuson.com_ERASE@ns.sol.net> In-Reply-To: <200210281311.34328.djohnson_acuson.com_ERASE@ns.sol.net> From: hawkeyd_ERASE@visi.com (D J Hawkey Jr) Subject: Re: FreeBSD vs Linux For Managers... X-Original-Newsgroups: sol.lists.freebsd.advocacy To: DavidJohnson_ERASE@Siemens.com, freebsd-advocacy_ERASE@FreeBSD.ORG Content-Transfer-Encoding: 8bit Content-Type: multipart/mixed; boundary="=-=-=__GB7Su6m+ILzb1Xj4KFNMyvbBR__=-=-=" Sender: owner-freebsd-advocacy_ERASE@FreeBSD.ORG List-ID: List-Archive: (Web Archive) X-Loop: FreeBSD.ORG Precedence: bulk --=-=-=__GB7Su6m+ILzb1Xj4KFNMyvbBR__=-=-= In article <200210281311.34328.djohnson_acuson.com_ERASE@ns.sol.net>, DavidJohnson_ERASE@Siemens.com writes: > > [SNIP] > > We are all set to go to roll out FreeBSD to the other lab workstations. But > some Linux advocate in the company is starting to raise a stink (even though > he is unwilling to help in the conversion and subsequent maintenance). Now > the manager in charge of the machines wants a report on why FreeBSD was > chosen instead of Linux. Sigh. I went through this exercise at my last job, except that "we" in my case was just me, and the workstation was a firewall. I was the only one of six that had any objective experience with both FreeBSD and Linux, though the other five certainly had their opinions, anyway. None were willing to assist in the conversion of the Linux firewall to FreeBSD, not out of hostility, but for lack of experience with FreeBSD. I was to have sole responsibility for the firewall. > So what good reasons translated into Manager-ese can I present? See the attachment for a pros-n-cons list I threw together, and presented to and discussed with my boss over a couple of beers at the local tap. It's rather dated now (FreeBSD 4.3, IIRC, versus RedHat Linux 6.2), but I think it still has many valid points. Host names and addresses have been changed to protect the innocent. It was a major factor in implementing the firewall under FreeBSD. > Thanks, > David Johnson HTH, Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" --=-=-=__GB7Su6m+ILzb1Xj4KFNMyvbBR__=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="Linux-vs-FreeBSD.txt" =========================================================== UNSCIENTIFIC COMPARISON OF REDHAT LINUX 6.2 AND FREEBSD 4.3 =========================================================== Linux FreeBSD ------------------------- ------------------------- Cost: $0 $0 Vendors/Dists: many OSes, 1 kernel 1 (1) License: GPL "Free Beer" (2) Hardware: most any i386 thang not the newest as quickly Support: vendors, users vendor, users (3) Audits: vendors, GNU, Linus vendor (4) Availability: high high Applications: bleeding-edge, established cutting-edge, established (5) Support: vendors, users vendors, users (6) Availability: high high Stability: lauded, but questionable high and well-known (7) Security: largely unknown high and well-known (8) Scalability: SMP SMP, Dummynet (9) Performance: high high (1) Linux has many distributions supporting a common kernel. Even among any one distribution, vendors often add or change things. FreeBSD has one distribution, and daily snapshots of the stable and current distribution tress are available. (2) The GPL is seen by many companies as anti-business, as it requires that any work derived from GPL'd code must be returned to the copyright owner (the public). FreeBSD's license make no such requirement. (3) Linux's support is muddied by the several distributions; what may work for one might not for another. Both enjoy a robust and active user community. On-line documentation for RH-Linux is inconsistant, at best. FreeBSD's man pages are exemplary. (4) Linux relies chiefly on the credentials and skills of all that contribute to the GNU effort for the OSes. Linus controls the kernel, and keeps a staff of trusted lieutenants. All the BSDs have a core peer group that steers and commits code, with an established and known hierarchy of teams for support, auditing, etc. beneath it. (5) For a long time, the BSDs were the platform of choice for development. Linux seems to be the OS of choice these days. Portability is high where the kernel is not involved. FreeBSD can run the majority of Linux, SCO, and SysV apps "natively". (6) Pre-packaged software abounds for both. Linux's is somewhat disparate in that each distribution has it's own list of packages, package manager, etc.. FreeBSD's is uniform and consistant. On-line documentation for RH-Linux is inconsistant, at best. FreeBSD's man pages are exemplary. (7) Linux's EXT2 filesystem, the default, is known as weak where disaster recovery is concerned, though quite fast. UFS is available? FreeBSD's FFS has years of proven robustness, though it's slower. Softupdates adds to it's stability, and puts performance on equal ground. Linux's process, memory and swap management is considered suspect under stress. FreeBSD's kernel is known for solidity, if not breakneck speed. FreeBSD's TCP/IP stack is considered second-to-none. One Linux vendor is known for putting release schedules before code readiness. FreeBSD has often postponed a release for code readiness. (8) Going beyond the "usual UNIX" methodologies and tools, Linux is largely untested in terms of cracker successes. FreeBSD has years of refinement and fixes behind it, and benefits from it's siblings' progresses. Both are good about notifying the user base to known exploits and their fixes. More and more Linux exploits are being announced. FreeBSD has "wheel". FreeBSD has "jail". (9) Dummynet: Can be used for bandwidth shaping. Bandwidth limiting handled in kernel. I myself have found typos in RedHat init scripts that could cause failure. I have yet to resolve another init script failure. I have witnessed TCP/IP interfaces stop reponding. I have seen a Perl script cause a kernel panic by spawning 'sendmail'. My own RedHat box just "went away" one morning. RH 6.2 is at end-of-life. Updates are becoming fewer. The 'rpm' utility itself has undergone a not-backward-compatable upgrade. Archived RPMs on non-RH servers are growing stale, and will dwindle. RH-Linux, even with a "server" install, installs too much Gucci stuff, and enables nearly everything. FreeBSD's installation of any level installs just what is necessary, and disables nearly everything. Linux has no hard- and-fast disk order, BSD's is well-defined and adhered to. RH-Linux installs no security mailings (or, at least, doesn't enable them), FreeBSD does. [sheol] /usr/home/hawkeyd$ sudo nmap -sS -O RH-6.2_server Starting nmap V. 2.53 by fyodor_ERASE@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on (nnn.nnn.nnn.nnn): (The 1513 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 24/tcp open priv-mail -> accounted for 25/tcp open smtp 26/tcp open unknown -> accounted for 27/tcp open nsw-fe -> accounted for 28/tcp open unknown -> accounted for 515/tcp open printer 1407/tcp open dbsa-lm -> accounted for 8080/tcp open http-proxy TCP Sequence Prediction: Class=random positive increments Difficulty=5752230 (Good luck!) Remote OS guesses: Linux 2.1.122 - 2.2.14, Linux kernel 2.2.13 Nmap run completed -- 1 IP address (1 host up) scanned in 32 seconds [root@host24 /root]# nmap -sS -sU -O FreeBSD-4.n_server Starting nmap V. 2.53 by fyodor_ERASE@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on (nnn.nnn.nnn.nnn); (The 3080 ports scanned but not shown below are in state: filtered) Port State Service 22/tcp open ssh 80/tcp open http 113/tcp closed auth TCP Sequence Prediction: Class=random positive increments Difficulty=48251 (Worthy challenge) No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: TSeq(Class=RI%gcd=1%SI=B903) TSeq(Class=RI%gcd=1%SI=10E49) TSeq(Class=RI%gcd=1%SI=BC7B) T1(Resp=Y%DF=Y%W=805C%ACK=S++%Flags=AS%Ops=M) T2(Resp=N) T3(Resp=Y%DF=Y%W=805C%ACK=S++%Flags=AS%Ops=M) T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) PU(Resp=N) Nmap run completed -- 1 IP address (1 host up) scanned in 452 seconds --------- NOTE: FreeBSD-4.n_server logged the probes in /var/log/security, and showed proof of bandwidth limiting. RH-6.2_server logged nothing. UDP probes were prohibited by FreeBSD-4.n_server because of it's own firewall rules. Many other "high" open ports on RH-6.2_server. --------- [root@host24 /root]# nmap -sS -sU -O another_FreeBSD-4.n_server Starting nmap V. 2.53 by fyodor_ERASE@insecure.org ( www.insecure.org/nmap/ ) Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap run completed -- 1 IP address (0 hosts up) scanned in 36 seconds [root@host24 /root]# nmap -sS -sU -O -P0 another_FreeBSD-4.n_server Starting nmap V. 2.53 by fyodor_ERASE@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on (nnn.nnn.nnn.nnn): (The 3080 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 80/tcp open http TCP Sequence Prediction: Class=random positive increments Difficulty=37723 (Worthy challenge) Remote operating system guess: CABLETRON Systems, Incorporated, Module Firmware Revision: 01.01.01 Nmap run completed -- 1 IP address (1 host up) scanned in 31 seconds --------- NOTE: another_FreeBSD-4.n_server logged the probes in /var/log/security. --------- --=-=-=__GB7Su6m+ILzb1Xj4KFNMyvbBR__=-=-=--