APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Early opinions of Linux vs. BSD

© December 2004 (various authors)

Taken from a newsgroup post

From: Bill Vermillion <bv@wjv.com>
Subject: Re: Linux vs FreeBSD vs SCO
Date: 26 May 2005 19:21:06 -0400
Message-ID: <20050526232033.GB8793@wjv.com> 
References: <Z_2dnfNJ-NSFehLfRVn-ow@rogers.com>
<20050526172539.GA17632@lonestar.cactus.com> At Thu, May 26, 2005 at 13:25 , our malformed and occasionally flatulent friend Jeff Hyman spewed forth this fount of brain juice: > -------------- clipped ------------- > | If you want to go back to your "Golden Unix Years" [ or more likely > | the Xenix years ] I'd suggest the FreeBSD 4.11. It will run on > | current hardware. You didn't say what hardware you are going to be > | running on but some of the older SW doesn't like the new hardware. > | I'm getting older and older - and there seems to be no way to > | preventing that is acceptable - and I took over the tech side of > | two different ISPs when I was older than you are now. > | My first BSD experience was a 2.6, and it was like going back to > | Xenix 1.x on my old Radio Shack 16 - where I got hooked on Unix in > | 1983. All of a sudden I was 'home again' and you're not supposed > | to be able to do that [see a comment in a reply to a post by Tony]. > | And speaking from the vantage point of a few year older than you, > | one thing that keeps me from getting older [mentally] is learning > | new things. And JPR and Bob Stockler - both on this list - are > | older than I. And even my son says "you are interesting to be > | around". What greater compliment could I get? > | Bill Vermillion - bv @ wjv . com > Bill, > I changed the Subject header to avoid thread drift. > If you had a choice between FreeBSD or Linux or SCO, which would pick?= > and why? I'm also curious how FreeBSD stands in the current *nix wars > compared to the rest. I do value your input as well as anyone else here= > that has had a taste of SCO|Linux|FreeBSD. I'm just curious. My last two SCO accounts de-commissioned their machine earlier this year. One move to a custom application with a web interface using MySql on Linux from Novel. That custom ap cost more than most of the databases out there, but the client worked a deal with the developer, and gets commissions on all further sales. Highly specialized and nothing available did exactly what they needed. The other moved to an NT platform - as their software vendor for their pharmacy finally got it converted from SCO to NT. That was being promised for 3 years. I wound up upgrading that machine to OSR5 for Y2K as the transition from SCO to NT was originally targeted for that time frame. The problems >>I<< have with Linux is it is not consistent. And it changes. They don't seem to have the concept of legacy systems, so that if they change something they expect you to upgrades. When - at one time - the ps -af deprecated the '-' and would bail out when it encountered that in a script I was told "change the scripts". The don't understand that some system have scripts that have worked for years the old way, and sometimes those scripts are called only rarely so breakage may occur later and you might not know why. This happened in the past and I've not done a lot with Linux recently - except for two sites I keep running. All my servers are FreeBSD. My mail server is getting upgraded this week as the volumes of mail it's woefully under-powered. I just checked in and it's been up and running for 459 days, and that's when I upgraded the OS on February 21, 2004. Exceptionally stable. I've also had SCO machines stay up that long but got really strange in displaying things on one that was up for at least 2 years. Another think I disliked was their 'better' way of firing off init scripts. Instead of the text oriented inted.con with one line for things they instituted the xinetd.conf file and xinetd.d diretory. Each file in xinetd.c has about 8 lines inside { and } with all it's options. disable no, or disable =3D yes certainly is more complex than just commenting out, or adding a line in /etc/inetd.d In the SGI system V there was an etc file that had one line for each service with the enable or disable, but it wasn't as overly wordy - or MSish - as the Linux thing. Of course this structure made it easy to parse things with their graphical front end. But and make this a _ _ _ _ | |__ (_) __ _ | |__ _ _| |_ | '_ \| |/ _` | | '_ \| | | | __| | |_) | | (_| | | |_) | |_| | |_ |_.__/|_|\__, | |_.__/ \__,_|\__| |___/ They way it was implanted [maybe it's changed] goes against all things I ever learned about robustness in servers - and I only putz around with servers. One day I got a call from xyz [running your SW so you can see who they might be] that nothing was working. Mail was down, telnet was down [and they had a great many users telneting in to use pine for mail] the web server was down. I inherited that when the other system admin [really excellent Unix person from the days of the old Gould Fire-breathers if anyone remembers them] went on to other things. But they have a lot of email users remotely who had always used telnet and that was not going to change. I was able to ping, then I performed a secure shell login and found the system was running but nothing >>NOTHING<< that was in xinetd was running. I restarted xinetd, and things started running and immediately stopped. It did the same thing. Reading the docs I found out how to start the logging and started it up that way. I looked at the logs and 18 services started, and then it found a configuration error in the ftpd startup. What caused that error I never found out. BUT - when it found that error, it bailed out and took everything else with it. IOW on failure in xinetd stopped everything else. That's more like an MS machine than a Unix. I don't use Linux that much but these few things made me dislike it. [I think you can tell I'm prejudiced. I got a Radio Shack 16 in 1983 and moved by BBS to that in 1984 and made it a Usenet node Then there is the rpm upgrade path. That also seems so MSish, as often you install an upgrade, and you find it needs something else, so you install that. And often you get library errors - just like MS gets those DLL things. In FreeBSD I almost always - with about 3 exceptions - build everything on the machine. I got to /usr/ports/<category><pgm> and type 'make'. These exceptions in case you are interested are things such as installing cvsup, which I do from a pre-built package, from packages otherwise it has to compile Ruby, and some other programs, that are used only for the compile, and that can take a long time. It goes to the net, gets the needed source code, sucks them in, compiles them, checks for all needed dependencies, compiles them, and then with make install it checks if there are other dependencies and brings them in and installs them. Some of the Linux dists are starting to adopt thins. With this method you almost never worry about outdated libraries, because we are compling on a running system. And often you get new libraries in addition to old ones. And for things such as shells, and at least through all the 4.x series of FreeBSD EVERYTHING in /sbin is compiled statically, so that each program can run all by itself and not depend upon any libraries at all. And I really dislike 'bash' that is the stock dist in Linux. And when I got into one of those I have to unlearn my ksh leanings, or install ksh there. That's personal preference. The newest BSDs have gone dynamic, but you do have an option to make those core files static. To me this is the only way as worst case you can move a file into a broken system if needed. In short the FreeBSD has evolved from the real BSD which came =66rom the old Unix systems. And there is no concept of a different kernel and user-land. When you build a system you build a kernel and all associated files so there is nothing to get out of sync. FreeBSD appears to be designed, and so much of Linux appears to have just happened. There is also a saying in the BSD group that goes something like this. "Linux is for MS haters. FreeBSD is for Unix lovers". That seems to have a degree of truth in it. I see many converts from Linux in the FreeBSD group. But it's not as desk-top oriented as Linux. And in many Linux installs you don't do anything but put in a disk or two, and use up about 2GB to put everything onto the system. OTHO I've put a running FreeBSD on a 800MB drive and had 400MB for user stuff. It's solid and runs and runs and runs. I've never had a server crash, and when it's upgrade time it's the only time they get rebooted. I may have been lucky, but when installing a new OS on a remote server, it's off line two times for only about 5 minutes maximum, each time. I run cvsup out of cron nightly to update the sources [ and for the servers I only get the release patches for security holes ] and when it's time to install a new one, I just go into /usr/src. And I run 'make buildworld' under nohup and logout, and come back later to examine the output. If that works I do the same on 'make buildkernel KERNCONF <nameforthatmachine>, and I check later to see if it's ok. The if all goes well about 1AM or so, I just perform 'make installkernel KERNCONF <nameforthatmachine>, which takes about 30 seconds. The I do a remote reboot, fire off ping locally, and typically in about 60-90 seconds I get pings back, and then ssh in. If I don't get the pings back the system is locked. That means a 15-20 minute=05 drive to the site after 1AM [traffic is lighter then - both on the net and on the road. The machine are inside the local Level 3 facility and I have 24x7 access.]. Then when the new kernel is running, I perform 'make installworld' and ALL the binaries in the system are updated to the latest compiled versions. I then run 'mergemaster' which compares all the old config files with newly compiled ones, and I make the choice of keep the old, install the new, or merge the files with the utility that compares both and I select what lines to keep in the merge. That never takes more than 20 minutes. Another reboot, and I'm done with that upgrade for another year. <hopefully>. I've only had about 2 upgrades that required rebuilding the kernel and rebooting - as they were library related. Most of the patches just required changing to the sources of the module, and then perform make clean, make, make install. It's a dream to maintain. And when I have to move our busiest site - www.springbreak.com [which when it got to 300,000 spam messages received per day had all it's MX pointers removed - built a parallel machine and changed IPs on the fly without rebooting. Disable the main IP [there were other IPs there] and since I had logins to both machine simultaneously I enable that IP on the upgrade machine. Total time it was inaccessible was less than 15 seconds. MS has finally figured out how to change IP's without rebooting - but that doesn't seem to be universal. At the first ISP for which I was running the tech side - it was all SGI. We all had SGI Indy workstation, and the servers were Challengers - small devices - not the big desk side units. Those were running 400Mhz or maybe 500MHZ MIPS 4000 RISC processors, and running the commercial Netscape servers and SGI distributed sendmail. 256 or 512MB of ECC memory. I moved the web sites to a 150MHz [or maybe 120Mhz] Pentiums with 128MB memory and FreeBSD 2.8 [maybe 2.7 it was a long time ago] and Apache, and performance went way up. The FreeBSD was much leaner than the SGI's IRIX which was basically a System V.4. I will say this however, the SGI's had the cleanest installs and upgrades and when there were conflicts you were told and had the choice to remove the programs that conflicted or not install the new program. The only thing I miss about the SGIs is their SCSI utilities which let you do anything to the drive you wanted - change vendor IDs, change sectoring, magnificent diagnostics and test suites, with the caveat you had to know what you were doing because one mistake meant a drive might have to go back to the factory. I'm getting ready to bring up a more powerful server, as we have been testing the Darwin Streaming Server and it works fairly well. Our colo facility has all the things needed for us to start multicasting on streaming video, which is something not a lot of ISPs are willing to do. We pulled a suite of sites from ?? [I forget who it was - but one of the biggest] because they couldn't do the extra steps in customizing things. And it wasn't that difficult. I'm getting the distinct impression that there is a dearth of technical ability at some ISPs. We're doing niche market hosting. But a couple have some very impressive members. If you don't recognize the general and principal members at www.aafassociation.org then you have not been paying attention. :-) Just put me down as an old Unix guy. Set in my ways, lazy so I pick systems that are easy to keep running and administer, and still love to play with technology - 28 years after I got my first computers. Bill -- Bill Vermillion - bv @ wjv . com

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Some early opinions of Linux vs. BSD

Inexpensive and informative Apple related e-books:

Take Control of Automating Your Mac

Take Control of Upgrading to El Capitan

Photos: A Take Control Crash Course

Photos for Mac: A Take Control Crash Course

Take control of Apple TV, Second Edition

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

We must be very careful when we give advice to younger people: sometimes they follow it! (Edsger W. Dijkstra)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode