Slashdot Mirror
BSD For Linux Users
noackjr writes "Matt Fuller posted among his rants a great introduction and explanation of BSD For Linux Users: 'It's been my impression that the BSD communit{y,ies}, in general, understand Linux far better than the Linux communit{y,ies} understand BSD. I have a few theories on why that is, but that's not really relevant. I think a lot of Linux people get turned off BSD because they don't really understand how and why it's put together. Thus, this rant; as a BSD person, I want to try to explain how BSD works in a way that Linux people can absorb.'"
What is this?
I run FreeBSD on my computers. A lot of my friends run Linux, or at least one of the distributions of it. Naturally, then, we agree that a Unix-style operating system is the right choice, but we disagree on which to use.
It's been my impression that the BSD communit{y,ies}, in general, understand Linux far better than the Linux communit{y,ies} understand BSD. I have a few theories on why that is, but that's not really relevant. I think a lot of Linux people get turned off BSD because they don't really understand how and why it's put together. Thus, this rant; as a BSD person, I want to try to explain how BSD works in a way that Linux people can absorb.
While there's overwhelming similarity between the operating systems in most cases, there are also a lot of differences. As you probe more into the differences, you find that they emerge from deep-seated disagreements. Some are disagreements over development methodology, some over deployment and usage, some about what's important, some about who's important, and some about which flavor of ice cream is superior. Just comparing the surface differences doesn't tell you anything; it's the deeper differences that both explain and justify why each group does things the way they do.
What isn't this?
This is not:
* A list of command correspondances; "'netstat -rnfinet' on BSD = 'netstat -rnAinet' on Linux" and such things.
* How to do all the things involved in adminning and running a BSD box.
* Why you should use BSD instead of Linux.
* Why you should use Linux instead of BSD.
* Why you should use this BSD instead of that BSD.
* Why you should use this Linux instead of that Linux.
* Why BSD is Right and Linux is Wrong.
* Why Linux is Right and BSD is Wrong.
* Why I am a god and you should worship me.
I, personally, for me, believe (obviously) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one.
Some preliminary thoughts
There're a lot of philosophical disparity between the Linux world and the BSD world. And there are a lot of expressions about it out there. One I particularly like goes something like:
BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC.
Now, I like that quip, not because it's some sort of absolute revealed truth, but because it gives a very good feel for some of the differences. The BSDs, in general, are very much more like traditional Unices than Linux is. A lot of that is because they're direct-line descendants of the BSD from Berkeley, which was a direct-line descendant of the original AT&T Unix. Unix-the-trademark is a trademark of The Open Group, and Unix-the-code is owned by SCO, so one can't actually say that the BSDs are really Unix (that's the sort of statement that triggered the USL/UCB lawsuit extravaganza, in fact). But, in many ways, the BSDs are direct derivatives of traditional Unix.
That shows through in a lot of ways. It shows up in the design of the base system and the packaging of addons. It shows up in the partitioning of the mass storage. It shows up in a lot of details of the commands. And it shows up in the attitudes and reflexes and prejudices of the developers, which are reflected in the code and in the users.
BSD is designed. Linux is grown. Perhaps that's the only succinct way to describe it, and possibly the most correct.
Where to begin?
...the rant says "Forbidden You don't have permission to access /~fullermd/rants/ on this server. Apache/1.3.27 Server at www.over-yonder.net Port 80" and the main link says "Warning: main(../../php_inc/styleswitch.php): failed to open stream: Too many open files in system in /home/fullermd/public_html/php_inc/main.php on line 16 Warning: main(): Failed opening '../../php_inc/styleswitch.php' for inclusion include_path='.:/usr/local/share/pear:/usr/local/s hare/smarty') in /home/fullermd/public_html/php_inc/main.php on line 16 Warning: main(../../php_inc/ahem.php): failed to open stream: Too many open files in system in /home/fullermd/public_html/php_inc/main.php on line 19 Warning: main(): Failed opening '../../php_inc/ahem.php' for inclusion (include_path='.:/usr/local/share/pear:/usr/local/ share/smarty') in /home/fullermd/public_html/php_inc/main.php on line 19 Fatal error: Call to undefined function: print_ahem() in /home/fullermd/public_html/TEMPLATE.php on line 94".
Could someone please be kind enough to post a mirror?
--
FreeNET user? Comfortable with the adverse selection?
Don't forget the power of USE flags. One of the things that I love about gentoo more than anything else is the power that USE flags give me. Want a server without any X compiled into the programs you're installing? Set USE="-X". Want to make sure that ssl is enabled everywhere that you have the option? USE="ssl". Want KDE instead of gnome for programs that have multiple GUI interfaces? USE="kde -gnome". Easy and powerful.
Who are the characters?
Meet the players
I'll give here a quick introduction to and discussion of the systems I'll be talking about. Note that the histories presented are not comprehensive or authoritative, and no attempt has been made to make them that way. Deal.
Unix
Unix isn't (precisely) an operating system.
Well, it is, and it isn't.
In specific usage, Unix is an operating system originally developed in the late 60's at Bell Labs by Ken Thompson and Dennis Ritchie. Over the years since then it's been developed and distributed as a commercial operating system, and a research operating system, by Bell Labs and USG and USDL and ATTIS and USL and Novell and SCO and anybody else who could come up with an acronym.
It's probably not too much exaggeration to say that Unix is the single most influential operating system in modern computing. Every general-purpose computing device you'll find, and a lot of specific-purpose computing devices, will be using ideas and concepts and often code from something in the Unix family tree.
When we use the word 'Unix', then, we far more often mean the general form, than the specific OS that carries the name Unix(TM). The general form means "Any operating system which, in design and execution and interface and general taste, is substantially similar to the Unix system." That means all the BSDs, Linuxen, SunOS, Tru64, SCO, Irix, AIX, HP/UX, and a cast of hundreds or thousands of others.
I'm not interested in getting into semantic discussions about how many angels can dance on a head of split hair. Let it suffice that when I use phrases like "Unix systems", I mean exactly what you think of when I use the phrase. Pedantry City is ---> that way.
Linux
Linux also means several things. It's a kernel, originally written by Linus Torvalds when he was a student in Finland. Since then it's been beat up, punched around, tweaked, poked, prodded, manged, digested, spit out, stomped on, chewed up, tossed out, brought in, and otherwise manipulated (not necessarily in that order, of course) by more other people than you could easily count.
Linux is also the term for a family of operating systems. While there are fascinating metaphysical discussions taking place in dozens of places around the world at this very second (I guarantee it) about how "Linux isn't really an operating system, it's just a kernel", or "It should be called 'GNU/Linux'", or similar topics, I'm also going to neatly avoid that semantic cesspool. When I say "Linux", I mean Red Hat. I mean Slackware. I mean Mandrake. I mean Debian. I mean SuSe. I mean Gentoo. I mean every one of the 2 kadzillion distributions out there, based around a Linux kernel with substantially similar userlands, mostly based on GNU tools, that are floating around the ether.
BSD
BSD stands for "Berkeley Software Distribution". Originally, it was a set of patches and extra add-on utilities for the official Bell Unix system that were developed by the CSRG at the University of California, Berkeley. Over time, it evolved to change and/or replace more and more of the system, until at some undefined point it became basically its own OS that merely happened to share chunks of code with Bell's Unix system.
Of course, it still required that you have a Bell license to use the system, since a lot of it was still Bell's code. All of the code written by Berkeley, however, was released under what's come to be known as the BSD license, which basically translates to "Do whatever the hell you want with the code, just give us credit for writing it". And a lot of the BSD code ended up working its way back into the "official" Unix system too, in System III and System V. And, a lot of both strains worked their way into the various commercial forks of Unix.
After the CSRG (mostly) dissolved and stopped developing the BSD system, several groups went off different ways with the code. One of these was the 386BSD project, which took the BSD code and made it run on the Intel i386 platform.
Help Brendan pay off his student loans
BSD is designed. Linux is grown. Perhaps that's the only succinct way to describe it, and possibly the most correct.
/.er who posted the first page, but the author).
He jests (not kind
BSD has grown from each previous BSD and then from each previous UNIX. How he can say this is more "designed" than Linux I'm not sure.
Sam
blog.sam.liddicott.com
The BSDs all keep the system under revision control; all the free BSDs use CVS. Revision control (in extremely brief) is a process by which editing a program means checking out a file or group of files, making the changes, then checking in the new versions, along with a message describing the change. A full history of all changes is kept in the revision control system, so you can view a history of the changes, check out an old version, look at the differences between arbitrary versions, etc.
All the BSDs provide public access to their CVS repositories in one way or another; generally through anonymous CVS, or CVSup checkout or mirroring, or often both. That means that, as a user, you can see exactly what changes happened when, who did them, and why they did them. You can also always get your hands on the latest changes (within a few hours, anyway, depending on mirroring strategies). All of the free BSDs have mailing lists that you can subscribe to and see the changes as they're made. In fact, they all have web frontends as well; you can poke around FreeBSD's entire source tree online at http://cvsweb.freebsd.org/src/, and see all the history of every file.
Linux, historically, hasn't used any version control for the kernel. I don't have exact data at my fingertips here, but I believe it was somewhere in mid-2.4 days that the kernel began being kept in a public BitKeeper repository. Many of the other utilities use revision control, but since they're all developed separately, there isn't any central place you can go to to look through the changes. So it's sometimes hard to get a historic picture of even any one part; to so do for a whole distribution is practically impossible.
This leads to a lot of differences. In a very real sense, BSD systems are constantly developed; I can always update my system to the absolute latest code, irrespective of "releases". In Linux, that doesn't really have as much meaning, because the release process is very different. I think the most appropriate verb for a Linux release is "assembled". A Linux release is assembled from version A.B of this program, plus version C.D of this program, plus version E.F of this program... all together with version X.Y.Z of the Linux kernel. In BSD, however, since the pieces are all developed together, the verb "cut" makes a lot more sense; a release is "cut" at a certain time.
Linux releases kernels in two parallel lines (well, often more than 2, but we're simplifying); a version with an odd minor release number, as a "development" version, and a version with an even minor release number, as a "production" version. The BSDs also have "development" and "production" tracks, but they're handled rather differently.
CVS, like most version control systems, has the concept of "branches". It's easy to understand, but somewhat difficult to explain. Basically, when you "branch" a file or a set of files (or a whole directory tree), you create a new version of the file which exists in parallel with the primary version. When you make changes to the primary version, it doesn't affect the branched version. And you can make changes to the branched version without affecting the primary.
In FreeBSD, there's usually 2 active development lines; one called "-CURRENT", which is the development version, and the other called "-STABLE", which is the production version. Both, of course, are under development, and both have some attempt to be made to keep them usable. -STABLE, as a rule, gets bug and security fixes, but only gets new features and such that are well tested, usually by a stint in -CURRENT first. -CURRENT gets new features, big architectural changes, and all those sorts of new development stuff. It should be noted that the naming of the branches doesn't necessarily mean what it seems to; while -STABLE usually is "stable" as in
Communit{y,ies} = {Community, Communities}
Because there are one or more BSD communities depending on how you look at it.
I'm one of those guys who used a lot of Linux, still like it on the server side and now I use OS X on the desktop side, but at the advice of some of the penetration testers I worked with, I decided to give OpenBSD a shot on my rebuilt home server.
/var/www and none else), but within hours someone posted a polite "Oh, try this".
It's one of those things where for a bit, I was a little confused on how things work. Granted, OpenBSD is not as "user friendly" on the install as, say, Red Hat 9, where you click the pretty buttons and things install. But thanks to a copy of "Absolute OpenBSD", I got it installed.
And I have to admit - for my server love, it's working pretty well. The ports system works like I'd always dreamed RPM's to work - tell it "install", and it gets the source, check it for dependancies, and go on.
The Flavor setting is another one I think I can live with, since you can specify there things like "Plaintext imap" versus default "secure imap" and the like.
And everything is right where I'd expect it. Ports installed files are in local, so now I can remember where everything is at once it's installed.
And it's pretty small - little "crufiness", and the community has been great. Like when I couldn't get Apache, PHP, and MySql to play. Turns out it was a socket issue (Apache on OpenBSD by default only wants to see things in
So far, as a server system, I'm beginning to groove on it. Perhaps if I wanted to run it as a desktop I might or might not have other issues, but since I've got a different OS for my desktop things, I'm pretty pleased with the BSD system.
Next up: learning how to upgrade. Not that I need to yet, but it's that "yet" that I'm anticipating. (Hey, there could always be another ssh exploit - you never know.)
52 Weeks, 52 Religions with John Hummel
The concept of the "base system" is something that, I think, causes the most trouble for people used to the Linux methodology. Which is perfectly understandable, because the whole idea just doesn't even exist in the Linux world.
Linux, from the start, was just a kernel. Without getting into the eternal debate of what an "operating system" precisely consists of, it's easy to state that a kernel by itself isn't very useful. You need all the userland utilities to make it work. Linux has always been a conglomerate; a kernel from here, a ls from there, a ps from this other place, vim, perl, gzip, tar, and a bundle of others.
Linux has never had any sort of separation between what is the "base system" and what is "addon utilities". The entire system is "addon utilities". MySQL is no different from ls from KDE from whois from dc from GnuCash from ...
Every bit of the system is just one or another add-on package.
By contrast, BSD has always had a centralized development model. There's always been an entity that's "in charge" of the system. BSD doesn't use GNU ls or GNU libc, it uses BSD's ls and BSD's libc, which are direct descendents of the ls and libc that where in the CSRG-distributed BSD releases. They've never been developed or packaged independently. You can't go "download BSD libc" somewhere, because in the BSD world, libc by itself is meaningless. ls by itself is meaningless. The kernel by itself is meaningless. The system as a whole is one piece, not a bunch of little pieces.
Now, X isn't a part of the FreeBSD base system. It's an addon package. Since X isn't part of the base system, X apps like xterm and KDE and Gnome and Mozilla and gaim and xmms and such obviously can't be part of the base system either. They're add-on packages, which are treated and thought of differently. The primary difference is where they're developed.
NetBSD and OpenBSD do have an X implementation in the base, because of the way they integrate it with their console driver. They both use heavily modified, very custom versions, so it's not feasible to keep it as a separate package.
The entire base system is developed together. To be sure, there're parts of the base system like sendmail and BIND and tcpdump and ssh and such, which are in fact individual packages which are developed elsewhere. There are even some GNU packages like groff and gcc and gzip and such, which will be immediately recognizable to any Linux user. But these are treated specially, in that versions are imported into the tree, then molded to fit the rest of the system. In fact, many of them used to be BSD-only; BIND and sendmail were originally developed at Berkeley as part of BSD, and only later became available separately. My FreeBSD system claims to be running gcc version 3.2.2 at this moment. Technically, it's not really gcc 3.2.2; it's a FreeBSD compiler based on gcc 3.2.2. The version of tcpdump I've got here isn't technically 3.7.2, it's a FreeBSD tcpdump based on tcpdump 3.7.2.
In most cases, of course, the FreeBSD version is practically indistinguishable from the vendor version. There're usually some changes to the compiling setup (Makefiles and such) to let it build cleanly with the rest of the system, and occasionally some necessary patches to make it compile and run right. Some changes are more extensive, and some are massive. But, they're all maintained together, and forced to play nicely together. There's a basic assurance that the pieces in a BSD base system all fit together, by design.
The primary reason an externally-maintained package becomes imported into and tracked in the base system is that it is, in some way, basic enough to the functioning of the system that it's easiest to have it there by default. FreeBSD currently uses the OpenSSH ssh server and client, which are integrated into the base system because, in this day and age, a secure remot
Typically, you don't have "Linux apps", exactly. What you tend to have are:
:)
1) open-source applications
2) Linux binaries
99% of what you tend to use on a Linux system falls under #1. It's not a Linux application, specifically. It's source code that compiles under Linux... and probably other OSes as well. Maybe the authors only use Linux, and are like "Well, this is written for Red Hat, but if you want to make it work on a different OS, take the source and hack it up" (shame on them). Or maybe they're decent programmers and don't write to a specific operating system.
The end result is that some source will compile fine on another OS, some might need special compile-time or configure flags set, and some might need some patching. You can do it yourself... or you can use FreeBSD's ports, which takes care of everything for you. If something is in the ports system, someone has taken the time to go through all that, and include it into the install process. Whatever it takes... compile-time variables, patches, dependencies, etc... it's all downloaded, patched, built (in the proper order), installed, registered in the database, etc.
The beauty of ports extends beyond just installing the software. Every file can be associated with its port. Dependencies are all tracked automatically, and using the "portupgrade" package upgrading is insanely easy and automated.
By the way, Linux binaries (category 2 from above) aren't a problem either... FreeBSD includes a Linux emulation layer that allows you to run them if they aren't available to compile natively. Examples are RealPlayer and the Flash plugins (the 2 Linux binaries I use the most). In fact, there's a whole section of ports dedicated to Linux apps.
I jumped from RH62 to OpenBSD3.3 some time ago. I have to admit that I've applied a lot fewer patches, security is much better, and the firewall is very powerful. In all, I'm happier.
However, I don't like:
And let's not even get started on Mac OS X.
The Ports System
Then, there's the second category; those programs which are add-on packages. In the BSD world, this is usually called the "ports system". That name is chosen for a specific reason.
Traditionally, when you wanted to run a package on your system, the first thing you had to do was compile it. And often before you could compile it, you'd have to fiddle with it. Your system would require different header files. Sometimes, manifest constants would be different. Sometimes, you'd even need to rewrite parts of it from scratch, because of basic assumption that didn't hold on your system.
Or, in other words, you'd have to "port" it to your OS, and/or to your specific system. The basic intent of the ports system is to do all that "porting" stuff for you. That it also automates building and installing, and provides packaging services (for things like 'uninstall') isn't as well reflected in the name.
But as with many things, it grew past its name into the beast it is today. The current FreeBSD ports collection has close to 10,000 packages in it (this number will, of course, be outdated quickly, but that's the nature of development). The most obvious feature of ports is that it builds things from source all the time, rather than just install pre-built binaries. This, it seems, is another one of those blatant differences that trip people up when trying to look at BSD from a Linux perspective. That it builds from source is just a side effect, it's not the primary purpose or difference. Binary packages are also available; in fact, binary packages are built from the ports tree!
Now, it's true that most Linux users install binary packages, and most BSD users install by building from source. Partly, that's a result of the tools; the ports system is designed around the concept of building from source, with the ability to make and install binary packages being something of an afterthought, while Linux packaging like RPM and dpkg and such are designed around the concept of installing a binary package, with building from source as an afterthought. Some of this is historical; binary packaging historically isn't a predominant theme in Unix systems, as I mentioned earlier. For that matter, packaging itself is a more recent thing. Traditionally, you'd deal with uninstalling and such manually.
Gentoo is a Linux distribution gaining in prominence these days. One of its big selling points is its portage system, which is often considered very similar to BSD ports. Perhaps most visibly, in that it compiles from source. That avoids a lot of the problem of binary packages. I've never used it myself, but the impressions I've gotten from information I've seen on it, and people I know who have used it, is that it's taken some good ideas from everyone, and smooshed them together. It'll be very interesting to see how it progresses and matures over the next few years. It's still much more Linux than BSD, but it may well be the closest to the BSD style of the major Linux distributions.
Now, there are advantages to pre-compiled binaries; mostly time (as in much less), and usually it'll take a lot less space to install a pre-compiled package, than it would to compile the package. There are also advantages to building from source, like avoiding all sorts of library versioning ugliness (my personal pet peeve with binary packages). You can install binary packages on Linux or BSD; you can build from source on Linux or BSD. But the users seem to be biased differently, because the systems are biased differently, because the users are biased differently... it all dovetails.
I guess what's important here is to realize that the difference between ports and RPM's isn't just that ports compile and RPM's just install. Ports are designed to cover the full range of bits and pieces of installing stuff; encoding and tracking and installing dependencies, packaging, installing and deinstalling, local changes necessary to build on your system, compile-time configuration tweaks... all those things. An RP
#include "sig.h"
The Ports System
Then, there's the second category; those programs which are add-on packages. In the BSD world, this is usually called the "ports system". That name is chosen for a specific reason.
Traditionally, when you wanted to run a package on your system, the first thing you had to do was compile it. And often before you could compile it, you'd have to fiddle with it. Your system would require different header files. Sometimes, manifest constants would be different. Sometimes, you'd even need to rewrite parts of it from scratch, because of basic assumption that didn't hold on your system.
Or, in other words, you'd have to "port" it to your OS, and/or to your specific system. The basic intent of the ports system is to do all that "porting" stuff for you. That it also automates building and installing, and provides packaging services (for things like 'uninstall') isn't as well reflected in the name.
But as with many things, it grew past its name into the beast it is today. The current FreeBSD ports collection has close to 10,000 packages in it (this number will, of course, be outdated quickly, but that's the nature of development). The most obvious feature of ports is that it builds things from source all the time, rather than just install pre-build binaries. This, it seems, is another one of those blatant differences that trip people up when trying to look at BSD from a Linux perspective. That it builds from source is just a side effect, it's not the primary purpose or difference. Binary packages are also available; in fact, binary packages are built from the ports tree!
Now, it's true that most Linux users install binary packages, and most BSD users install by building from source. Partly, that's a result of the tools; the ports system is designed around the concept of building from source, with the ability to make and install binary packages being something of an afterthought, while Linux packaging like RPM and dpkg and such are designed around the concept of installing a binary package, with building from source as an afterthought. Some of this is historical; binary packaging historically isn't a predominant theme in Unix systems, as I mentioned earlier. For that matter, packaging itself is a more recent thing. Traditionally, you'd deal with uninstalling and such manually.
Now, there are advantages to pre-compiled binaries; mostly time (as in much less), and usually it'll take a lot less space to install a pre-compiled package, than it would to compile the package. There's also advantages to building from source, like avoiding all sorts of library versioning ugliness (my personal pet peeve with binary packages). You can install binary packages on Linux or BSD; you can build from source on Linux or BSD. But the users seem to be biased differently, because the systems are biased differently, because the users are biased differently... it all dovetails.
I guess what's important here is to realize that the difference between ports and RPM's isn't just that ports compile and RPM's just install. Ports are designed to cover the full range of bits and pieces of installing stuff; encoding and tracking and installing dependancies, packaging, installing and deinstalling, local changes necessary to build on your system, compile-time configuration tweaks... all those things. An RPM is just a binary package. If you want to auto-install dependancies, you have to have a higher-level tool like urpmi or apt-get to do it. And, since it's binary, you have to deal with library versioning conflicts, or missing compile options, or any of the other limitations you incur by not building it on your own system.
And further, ports, like the rest of the BSD systems, are centralized. The "ports tree" is really just a big directory tree with a bunch of categorized directories, each containing a Makefile with some variable definitions, a checksum file, a packing list, and various other possible things. Each of those directories represents a single program, which is described by th
Did you know that "FTW" ("for the win") is a direct translation of "Sieg Heil"?
Then, there's the second category; those programs which are add-on packages. In the BSD world, this is usually called the "ports system". That name is chosen for a specific reason.
Traditionally, when you wanted to run a package on your system, the first thing you had to do was compile it. And often before you could compile it, you'd have to fiddle with it. Your system would require different header files. Sometimes, manifest constants would be different. Sometimes, you'd even need to rewrite parts of it from scratch, because of basic assumption that didn't hold on your system.
Or, in other words, you'd have to "port" it to your OS, and/or to your specific system. The basic intent of the ports system is to do all that "porting" stuff for you. That it also automates building and installing, and provides packaging services (for things like 'uninstall') isn't as well reflected in the name.
But as with many things, it grew past its name into the beast it is today. The current FreeBSD ports collection has close to 10,000 packages in it (this number will, of course, be outdated quickly, but that's the nature of development). The most obvious feature of ports is that it builds things from source all the time, rather than just install pre-built binaries. This, it seems, is another one of those blatant differences that trip people up when trying to look at BSD from a Linux perspective. That it builds from source is just a side effect, it's not the primary purpose or difference. Binary packages are also available; in fact, binary packages are built from the ports tree!
Now, it's true that most Linux users install binary packages, and most BSD users install by building from source. Partly, that's a result of the tools; the ports system is designed around the concept of building from source, with the ability to make and install binary packages being something of an afterthought, while Linux packaging like RPM and dpkg and such are designed around the concept of installing a binary package, with building from source as an afterthought. Some of this is historical; binary packaging historically isn't a predominant theme in Unix systems, as I mentioned earlier. For that matter, packaging itself is a more recent thing. Traditionally, you'd deal with uninstalling and such manually.
Gentoo is a Linux distribution gaining in prominence these days. One of its big selling points is its portage system, which is often considered very similar to BSD ports. Perhaps most visibly, in that it compiles from source. That avoids a lot of the problem of binary packages. I've never used it myself, but the impressions I've gotten from information I've seen on it, and people I know who have used it, is that it's taken some good ideas from everyone, and smooshed them together. It'll be very interesting to see how it progresses and matures over the next few years. It's still much more Linux than BSD, but it may well be the closest to the BSD style of the major Linux distributions.
Now, there are advantages to pre-compiled binaries; mostly time (as in much less), and usually it'll take a lot less space to install a pre-compiled package, than it would to compile the package. There are also advantages to building from source, like avoiding all sorts of library versioning ugliness (my personal pet peeve with binary packages). You can install binary packages on Linux or BSD; you can build from source on Linux or BSD. But the users seem to be biased differently, because the systems are biased differently, because the users are biased differently... it all dovetails.
I guess what's important here is to realize that the difference between ports and RPM's isn't just that ports compile and RPM's just install. Ports are designed to cover the full range of bits and pieces of installing stuff; encoding and tracking and installing depe
General
Ah, now this is the part I enjoy. Lots of soaring generalities, without a single hard fact in sight. Saves the trouble of having to do research. 8-)
What I'm going to discuss here is some of the real and imagined philosophical differences that both cause, and are caused by, some of the technical and organizational differences we've discussed. Like most such discussions, there's little that's hard-and-fast here; there's plenty of overlap in attitudes among people in the various camps. And there's certainly plenty of completely deserved flak for both sides to take, as well as undeserved flak they've been forced to. Still, I think it's important to examine some of these splits, without trying to presume that one is "correct" and the other is "incorrect".
Realize, I must emphasize, that a lot of this is very general. Practically every point is riddled with exceptions. And both systems often don't "follow the rules", or fail to meet their own expectations. It's more a question of inclination that of exceptionless implementation. I'm just saying this now, so I don't have to keep qualifying and re-qualifying every statement I make, until it's impossible to read.
Chaos vs Order
One common generality is that the Linux methodology is the living incarnation of chaos, whereas the BSD methodology is far more about control. To a large extent, it's true. Linux grew out of a spare-time hacking background, while BSD grew out of a controlled engineering background. Of course, there's plenty of weekend tinkers writing BSD code, and plenty of full-time professional programmers sloughing away at various parts of Linux. But the feel of the systems still does reflect that sort of schism.
We've already discussed the construction methodology; BSD builds up a core system which is uniform, whereas Linux distributions takes pre-existing pieces and pretty much puts them together helter-skelter. Naturally, the BSD method is far more amenable to keeping things ordered, while the Linux method practically necessitates utter chaos. That's not to say that chaos is inherently bad, or order inherently good. They're just different environments.
Linux will also generally chase new versions of other programs much more closely, adopting particularly more major changes like Apache 2 much sooner than BSD will move that way. Now, the stricter separation of "base" vs "ports" in BSD, as well as the structure of the ports tree itself, make it easier to have multiple parallel versions of packages in BSD. Sometimes, it's even possible and easy to have multiple versions installed at the same time. Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.
And the primacy of source-compiling in packages also makes it easier to handle multiple versions. For instance, PHP must be compiled differently depending on whether you're using Apache 1.3 or Apache 2. With from-source packages like ports, I can define an environmental variable when I compile and install PHP to tell it whether to use Apache 1.3 or Apache 2. With binary packages, you'd have to have 2 separate packages available, which will lead to confusion sooner or later.
Right vs Wrong
The difference can also be seen in the way core code is integrated. BSD tends to always shy away from hackish solutions when there's even a hint of a proper solution in the wings. The theory is that it's far easier to wait for the clean answer, than to integrate the dirty answer now, for several reasons. For one thing, if you integrate the dirty answer, that reduces the incentive to implement a better one. For another, once you dirty up the architecture to integrate something it'll never get cleaned up again. You know it as well as I do. Oh, sure, you'll say it's temporary. But you know
General
There're all sorts of myths and objections and "common knowledge" and "conventional wisdom" and such floating around about BSD. I'm always a little surprised at how quick some Linux people are to latch onto such over-simplifications and long-dead statements about the BSDs, especially since they then spend so much effort screaming about people doing the same thing concerning Linux. Oh well. Let's rip up a few.
Hardware
"BSD doesn't support common hardware."
Does Linux support hardware that BSD doesn't? Probably. Does it matter? Only if you have that hardware.
I'll betcha Windows supports hardware Linux doesn't. For that matter, MacOS probably supports hardware that none of the rest do. BSD supports most common hardware you'd stick in a server, most common hardware you'd stick in a workstation, most common hardware you'd stick in a desktop... There are gaps, but the gaps change from release to release, just like every other system.
Video card support, for instance, is hardly ever claimed in any BSD documentation, while Linux documentation talks about it a lot. That seems weird, until you realize that in the BSD worldview, the OS isn't supporting any of those video cards; X is, which is a separate package. So you can use any video card under BSD that you can under Linux, since neither the BSD kernel nor the Linux kernel is supporting the video card. Now, that's not strictly true, particularly in some of the more esoteric reaches of 3D and DRI, which require more direct hardware ties and more grubbing in the kernel itself. Of course, I don't follow that, so I don't even know what the current state of the world is in FreeBSD, to say nothing of Linux. Maybe BSD doesn't have support on a par with Linux on that. Maybe it does. I dunno, and it'll probably change between the time I write this and the time you read it.
But most hardware is simple. Most common IDE and SCSI mass storage controllers work just fine. Even most RAID controllers are supported to some extent. Most network cards, wired and wireless, most sound cards, some crypto-assist cards...
But it is simple. You don't care what hardware the OS supports, as long as it supports what you have. Read the hardware support lists and/or just try booting it up. You might be surprised.
When in doubt, check the lists. Hardware support lists are available per-release, such as the lists for 5.2-RELEASE and for 4.9-RELEASE of FreeBSD.
Program Availability
"But Linux has more programs than BSD!"
How do you figure? Most of these "programs" you're so hot about are things that are open source or source-available anyway. If it's written reasonably portably, 95% or better of it will compile right off on any vaguely POSIX-compliant system. Heck, just look in the ports tree; there are over 10,000 programs and packages there.
Of course, there's a lot of software out there that won't compile on anything but Linux. Sometimes, that's because it really does require facilities that only Linux has, or does things that only matter on Linux. Sometimes, that means you need to pick up a 2x4 and go find the author, because they've put in something gratuitously imcompatible through malice or laziness. There are people who do the same with BSD, or with HP/UX, of course, but the rapidly growing Linux community, combined with the number of people writing programs who have with less experience in traditional software engineering, make it far more visible there.
Of course, there are some things that won't cross-build, particularly those that stick their fingers deep in implementation details. Some require only a little work to port, some major work, and some don't even have any meaning on other systems (When did anybody ever port Mic
Check this article out!
/etc/format.dat file.
/etc/format.dat file, matching the geometry..." Uh-huh. After years of development and millions of dollars, Solaris still can't figure out how to label a disk drive. Give me, as they say, a break.
Title: Why I run FreeBSD - SunOS, Solaris, Linux? No, thanks!
Why I run FreeBSD
SunOS, Solaris, Linux? No, thanks!
Abstract
Rich explains why FreeBSD is the superior OS for him. (1,500 words)
Last month's column ("Serious FTP") discussed anindustrial-strength FTP site, based on a 200-MHz P6 ("Pentium Pro") and a pile of special-purpose
I/O hardware. Although my main server isn't trying to serve thousands of simultaneous FTP sessions, I still want it to be robust, easy to maintain, and convenient to enhance.
So, like Walnut Creek CDROM, I use FreeBSD. Specifically, I'm using FreeBSD 2.2.8; I'll switch over to FreeBSD 3.x in a while; for now, I'm just lurking on comp.unix.bsd.freebsd.*, watching the new development track's bug reports quiet down.
It's not that I haven't tried Sun's offerings; I have. In fact, I have both SunOS and Solaris running here, as well as a Power Mac (supporting the www.mklinux.org Web site).
However unwillingly, I have been initiated into the administrivia of a variety of Unixish systems. And, for a variety of reasons, I believe that FreeBSD is a clear winner over the others I have installed.
Why SunOS and Solaris lose I tried hard to retain the SunOS machine as my server. SunOS is a tidy (by current standards, at least) little BSDish operating system. Also, I am very familiar with its BSDish quirks, and it has been amazingly reliable, so I was strongly motivated to keep it going.
Unfortunately, SunOS has had no real support from Sun for several years. As a result, the system software is quite out of date. It has gaping security holes (e.g., ancient sendmail), annoying limitations (a "mere" 2 GB per filesystem), archaic development tools (no C++ or Perl), and some real oddities (no DNS without (yurggh!) NIS).
Patches and add-on packages could solve much of this, but there is no guarantee that they'll all play nicely together. In any case, I'm not into that degree of pain, so the SunOS box has been relegated to "experimental" use.
I have managed to avoid Solaris for several years, but I recently had reason to set up a Solaris system. I attached a CD-ROM drive and a pair of disk drives to the SCSI bus of a spare ELC and fired it up.
Everything went fine until Solaris looked at the disks. Then, because the disks didn't have Sun labels (well, duh!), the GUI installation procedure printed a nastygram and dropped me in front of a command-line prompt.
If this was a SunOS system, I would have known exactly what to do at that point: find a utility to get the exact size of the disks, fake up a plausible disk geometry to match the size(s), and edit the mess into the
You see, SunOS inherited the 4.2 BSD filesystem, which tries to employ disk geometry as a way to reduce head movement and rotational latency. Modern SCSI disks don't have fixed track sizes, however, so some parameter faking is required.
This, however, is Solaris 7, Sun's latest and greatest operating system. There must be a magic command to set things up on an "alien" disk drive. The fact that the GUI didn't call the appropriate routine is a bit annoying, but surely just an oversight.
So, I asked a friendly Sun support person for the answer. "Well, you have to find or create an entry in the
I won't even get into the issues of Solaris support tools, save to say that a Unixish system without a C/C++ compiler and Perl 5 isn't up to any standards I'd wish to set.
Why Linux loses (for me)
Part of my problem with Linux is subjective; As a long-term BSD administrator, I am simply more comfortable
Muchas Gracias, Señor Edward Snowden !
System Upgrades
Building the world in less than 7 days
As a result of the fact that the BSD base system is developed as a single unit, you can easily get the entire source tree for the entire base system. And because of the way it's designed, you can execute a single command at the top level to compile everything. For most of us, that's the normal way to upgrade; you update your source tree to the absolute latest (with a few hours, of course) changes made by anybody, compile it, install the new binaries, and you're done. Miller time.
Of course, you might not necessarily want the latest. You could grab the sources from last week, say. And normally, you do the whole rebuild process in four steps. You start with a make buildworld which compiles all of userland, then a make buildkernel which compiles the kernel. Then you take a deep breath and make installkernel to install the new kernel, and make installworld to install the new userland. Each step is automated by a target in the Makefile.
Of course, I'm leaving out tons of detail here. Things like describing the kernel config, merging system config files, cleaning up includes... all those gritty details. If you want to read about that, check the FreeBSD handbook, specifically the sections on updating and building and configuring your kernel, or the various other forms of documentation available. But those sort of things become second nature after you do them a few times. Really, the process of updating your system boils down to those four commands. I find it a lot easier than having to resolve cross-dependancies and changed library versions and such across a zillion binary packages.
This information is mostly based on FreeBSD. NetBSD uses a different model for doing the system builds. OpenBSD tends to be much more in favor of reinstalls, at least for major version changes.
Addon software
Well, that sure was easy. But, what about all those add-on packages? How do we manage those? Let's talk about installing and upgrading ports.
The only time there is a cost with using GPL software is when you change something and then distribute to people other than your own comapny. The you must supply the source code. If you keep it in house you have no problems. Unlike BSD which microsoft, SCO, SUN . all charge you for parts of BSD that they used over the years.
i thought once I was found, but it was only a dream.
Is how they insist that a community can or should behave as a monolith.
Linus, Gates, and Theo have no control over how their software communities behave. Their respective software communities have no control over how they themselves behave.
Yes, I realize my complaint has been voiced before. But all y'all jackasses are hard to drown out. Well. IHBT. IHL. HAND.
There are no trails. There are no trees out here.
You're off base with your comments.
Apple has released their changes when required, specifically KHTML, GCC, and others. They have also released their BSD codebase as Darwin, which is available at the following URL.
http://developer.apple.com/darwin/projects/
Feel free to look at all of the other code they have contributed. If you ask me, they're better than Microsoft simply because they participate. Microsoft doesn't do this, at all.
Maybe you're just writing flamebait and I'm a big sucker? Oh well.
1. If you installed some other UNIX it might have been equally cryptic. Ever installed AIX, IRIX, or Solaris?
/usr/local. There is a UNIX historical precedent for this, and for good reasons too. (Other OSes have the same theoretical layout, MacOS with "System Folder" and "Applications", Windows with "Windows" and "Program Files" although these examples tend have many internal inconsistencies.)
2. apache's not part of the base OS. thus these applicatoins live in
I started using BSD (v4.2 on a VAX) in 1983, years before I started using MS Windows (v1.2 in 1987)... and even more years before Windows came up with the BSoD (Win95 or WinNT?)
To be honest, CVS isn't all that hot as a VC system, compared to what could be done. The problem is that it's a pain in the ass to make a VC system, it's a pain in the ass to migrate from one to the other, and CVS has been there and free, so folks use it.
/proc out of box, this means that they can also do a fair amount of monitoring of what's going on.
Don't get me wrong -- using CVS is waaay better than no VC. CVS was the first VC system I used seriously (well, after a short stint with RCS). However, CVS is seriously hampered by trying to be highly compatible with RCS, which was never designed for the kinds of environments that CVS is used in.
Anyway, as to things that aren't that hot about CVS:
* CVS doesn't grok "text" files where the linefeed format matters. If you have a piece of software that uses a text file in CRLF format, you need to treat it as a binary format.
* CVS sucks -- badly -- from a security standpoint. The current feature branch is getting vaguely closer, fixing a huge number of symlink-related bugs present. Basically, something as simple as a repository where some folks have read access, some folks have read/write access, and some have no access to each module is a real pain to set up.
* CVS allows spoofing of version history. Bad, given that one reason folks like VC is that they treat it as auditable. CVS is *not* an auditing system that can be trusted for legal or security purposes.
* CVS does not grok the concept of files moving.
* CVS cannot version CVS metadata. This means that if you have a file checked in as text (accidentally), and at some point switch it to binary format, you must break all checkouts before the original date when you mark the file as binary.
* CVS understands things based on a file-by-file basis. While it's not too hard to write scripts to provide functionality like listing all tags used in a project, it's annoying that CVS can't handle this.
* CVS lacks some of the re-merging features that BitKeeper and more advanced VC systems have. I haven't needed to muck with this, but it's apparently one of the two big reasons that the Linux kernel folks don't use CVS.
* CVS can't do distributed, disconnected development. You have to have one server that everyone can talk to, full stop. This is the second major reason that the Linux kernel folks don't use CVS.
* CVS does not do atomic updates or checkouts across multiple files (as I said, CVS sees everything on a per-file basis). Frankly, our databases and filesystems all moved to transaction semantics long, long ago. A VC system has even less excuse not to have transaction support. CVS is way behind the times in terms of reliability -- theoretically, this can cause all kinds of nastiness.
* CVS makes it a real pain in the ass to delegate administrative access, and tends to not be particularly secure. For example, if I want to allow someone to add a module, and want some *subset* of the modules in a repository to generate commit notification messages, I need to give that person write access to CVSROOT/loginfo. Bad. (Again, you can write a program that provides this access, but it's not part of CVS.)
* The CVSWin GUI sucks, and hangs if CVS is processing anything. If you have anyone that doesn't use the CLI and uses Windows, life is annoying for them.
* Unless you want to do mucking about with secure shells, giving someone CVS write access means giving them shell access on the server. Because Linux (and, I suspect, most *IXes) don't support restricted
Really, to be honest, CVS was a cool system for when lots of people were using RCS. CVS's killer feature is RCS compatibility. Without this constraint, CVS would not have most of its drawbacks.
I haven't seriously checked out Subversion, but I'd like to see how well it stacks up. It certainly fixes at least some of the problems.
May we never see th
Mycrosoft's use of BSD code is both legal, and ethical, in that it is a voluntary action, done with the informed consent of both the parties involved.
However, that alternatives exist at all is not a test for Monopoly. If it were, there could never be a true monopoly, ever. A monopoly exists wherever those alternatives face constraints other than those of the market in surviving, gaining a share, or making a profit. Now you know why "everyone, even the court system", disagrees with you. It's legal to have a widely used product, all the way to 100% share. It's not legal to engage in what the court calls anti- competitive practices to protect or augment that share.
Refusing to sell to hardware vendors unless they do not enter into other contracts with your competitors, for example. Given that the hardware vendors are publicly traded companies, they cannot legally refuse to take such a deal, as the short term penalties to their own stock would be a violation of existing laws protecting shareholders. Ergo, a monopoly exists, at least so long as the shareholder protection law exists.
Maybe in a world where there were not a lot of other laws, monopoly would be as impossible as you seem to think it is. So, let's get rid of the Sherman anti-trust law, RIGHT AFTER we repeal all the other laws that made it vitally necessary. Better yet, let's figure out how to change these laws, a few at a time and with the overall goal of moving smoothly from Mercantilism to a true free amrket.
Who is John Cabal?
The problems seem pretty cut and dry.
Due to the change from a.out to ELF binary format in OpenBSD 3.4, upgrades can be a complex, delicate process. The best solution, whenever possible, is to backup your data and reinstall from scratch... In all cases, once you start the upgrade you MUST complete it. If the upgrade process fails or is abandoned before it completes you will almost certainly be left with a non-functional system... Finally, you cannot use the bsd.rd kernel to upgrade the system. The existing bootblocks on your system cannot boot the 3.4 bsd.rd.
Pardon me for reading the instructions.
Your copy, yes. But you're not alone in the world. You need a community to help you (seems like many BSD folks think they are an island).
FreeBSD has a community. So does NetBSD and OpenBSD. I don't need to achieve "world domination" in order to get good software. No matter what Microsoft does with it's copy of FreeBSD, my copy is still intact, along with the copies of those who develop it. It would change nothing in my life.
If the majority starts to use a closed branch of your code, then you lose something beyond the code - relevance in the real world.
This isn't a popularity contest. I could care less what the majority does. This isn't a zero-sum game. I only need enough people working on my chosen software to keep it going.
Last I checked, FreeBSD was growing fairly rapidly. It might not be growing as fast as Linux, but frankly, who cares? I have no worries that it's going to disappear in the next few years.
I hope that you recognize that this analogy doesn't make any sense. A proprietary derivative of a law has no significance for anybody.
The analogy was meant to demonstrate that no matter how much one changes their own copy of a document, the original document is unchanged.
Take another example. "Alice in Wonderland" is in the public domain. It is not copylefted. So along comes Microsoft and exploits it. They change the wording, the plot, dumb down the puns, etc. Then they release it under a proprietary license, charging a fee to read it (not merely a fee to purchase the paper it's printed on). Further, let's assume that their version of AiW becomes more popular than the original. Does this change anything? No, not really. It's sad that so many people are choosing to read the bastardized version rather than the original, but the original is still there and unchanged. There are no restrictions in place anywhere that prevent people from accessing it. Anyone who wants to can go get it and read it. It's still in the public domain.
Don't blame me, I didn't vote for either of them!
Not from the featured article, but from here:
4.4 What versions of BSD are available?
In contrast to the numerous Linux distributions, there are only three open source BSDs. Each BSD project maintains its own source tree and its own kernel. In practice, though, there appear to be fewer divergences between the userland code of the projects than there is in Linux.
It is difficult to categorize the goals of each project: the differences are very subjective. Basically,
*
FreeBSD aims for high performance and ease of use by end users, and is a favourite of web content providers. It runs on PCs and Compaq's Alpha processors. The FreeBSD project has significantly more users than the other projects.
*
NetBSD aims for maximum portability: ``of course it runs NetBSD''. It runs on machines from palmtops to large servers, and has even been used on NASA space missions. It is a particularly good choice for running on old non-Intel hardware.
*
OpenBSD aims for security and code purity: it uses a combination of the open source concept and rigorous code reviews to create a system which is demonstrably correct, making it the choice of security-conscious organizations such as banks, stock exchanges and US Government departments. Like NetBSD, it runs on a number of platforms.
There are also two additional BSD UNIX operating systems which are not open source, BSD/OS and Apple's Mac OS(R) X:
*
BSD/OS is the oldest of the 4.4BSD derivatives. It is not open source, though source code licenses are available at relatively low cost. It resembles FreeBSD in many ways.
*
Mac OS X is the latest version of the operating system for Apple Computer Inc.'s Macintosh(R) line. The BSD core of this operating system, Darwin, is available as a fully functional open source operating system for x86 and PPC computers. The Aqua/Quartz graphics system and many other proprietary aspects of Mac OS X remain closed-source, however. Several Darwin developers are also FreeBSD committers, and vice-versa.
At the very least, "Slashdotted" should be a 5xx code.
The codes are roughly:
1xx -- Not done yet
2xx -- You win
3xx -- You lose, but try again
4xx -- You lose; your fault
5xx -- You lose; my bad
Well in my case FreeBSD supported various server hardware before Linux did. e.g. SCSI controller.
Linux definitely seems to support 3D video cards before FreeBSD does.
And I still prefer ipfw to iptables. There are some things ipfw does that iptables can't do (and vice versa of course).
However FreeBSD choosing the m+n threading model seems to be betting on the slow horse to me. Linux appears to be picking a better method in that case.
FreeBSD is *NOT* a distribution. You can't pick and choose the kernel, the compiler, the ls app, the nice app, the init app, and so on to build your own. There is only 1 FreeBSD, and no matter who installs it, or how (FTP, CD-ROM, etc) you all end up with the *exact* same bits. It is an actual OS, with a kernel and userland developed in sync with each other.
Linux *IS* a distribution. You can pick and choose the kernel, the compiler, the ls app, the nice app, the init app, and so on to build your own, custom OS. This is exactly what the different distribution groups do. They pick and choose what they want to use, where they want to put it, how they want to configure it. You can never be sure if the distribution you use is compatible with the distribution your buddy is using. The kernel is developed completely independently from the rest of the OS. The individual userland apps are all developed independently of each other. It is up to the distribution groups to make all these independent apps work together. Linux is a kernel. A Linux OS is some version of the kernel bundled together with a hodge-podge of other apps that have (maybe) been tested to work together.
Do you see the difference now??
I've had much worse support from paid contracts and major vendors.
Someday I'll get around to trying this newfangled Linux thing out, but for now, the employer I'm looking at back home wants familiarity with BSD, and so my spare time is allocated.
Aside from what goes to the wife and kid, that is.