BSD vs Linux---FreeBSD for Linux user

盗版青春

http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php


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 thoughtsThere'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.
Meet the playersI'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.
UnixUnix 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™. 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.
LinuxLinux 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.
BSDBSD 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. As the 386BSD project wound down, two main groups took the 386BSD code to go forward with it; one was the FreeBSD project, the other was the NetBSD project. Later on down the road, some internal disagreements within the NetBSD project caused the OpenBSD project to split off from it.
When I say "BSD", then, I mean a number of things. I mean the general BSD flavor and approach to systems. Generally, I mean the above as typified by the 3 current freely available BSD systems:

• FreeBSD originally targetted getting the best possible performance on the 386 platform. Lately, it's expanded to a number of other platforms including Alpha and SPARC, as well as to the heirs of i386, Intel's Itanium, and AMD's Opteron. Its primary goal is to be as robust and efficient as possible on its various platforms, both for server and desktop roles.
• NetBSD is aimed at running on as many platforms as possible. Its goal is to be the most portable OS on the planet, and it seems to do a pretty fair job at it.
• OpenBSD is focused primarily (some would say 'solely') on security and related topics. Tight integration of security and auditability and cryptography and related issues are its primary goal.

All of those goals, of course, are fungible. Every BSD cares about and works on security. Every BSD cares about and works on performance. Every BSD cares about and works on portability. Massive chunks of code are shared among the group. Many developers work on more than one system.
Astute readers will note that I don't mention Mac OS X or its underlying layer Darwin as BSDs. While they're based on a mostly BSD foundation, the upper layers of OS X are pure Apple. Running OS X, as a user, you generally use it like MacOS, not as BSD. So while some of this might be applicable academically to OS X, it isn't of any practical value in understanding it. Darwin is closer to a standard BSD feel, but most of its userbase is people who came from BSD, so it's a bit outside the scope of this essay as well. Much of the general information, however, will probably transfer easily.
When discussing specifics in this essay, I'll be mostly referring to FreeBSD, because that's the one I personally run and am, by far, the most familiar with. On very specific points, there will be significant differences. The more general the point, the more likely it is to be the same across the group. Philosophically, all the BSDs are very similar, in contrast to the Linux methodology. And anyway, the philosophy is what this essay's about in the first place.
The Base SystemThe 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 were 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 remote access method is sufficiently basic to any system that it's a practical necessity. gcc and the binutils are part of the base system because... well, they're required to build the base system. X and Gnome and PostgreSQL and Apache and such are not part of the base system, and likely never will be, because they're not required to get the system up and deployed, won't be used on many systems, don't need that sort of close integration... many reasons.
It's important to emphasize this "base system" idea, since it is, I think, one of the most visible indication of the difference in development methodologies between BSD and Linux. A Linux distributor may put together the pieces and test that they fit before releasing. They may even have some customization on some of the packages. But it's rather different from the intense sort of integration done by BSD. Particularly in that so many of the components of the base system don't come from "somewhere else" in the first place; they've lived their whole lives as a part of the system.
Some Linux distributions (Debian and Gentoo, from what I understand, are particularly prominent members of this group) are much more similar to this base/ports split than others. They keep something of a line between what's necessary to get the system running, and all the other packages you might want to install on a system. What distinguishes this from the BSD base system is that most of those packages are still maintained elsewhere, and just "collected" into the Linux dist. There's no "Gentoo tftp", for instance; it's some package from somewhere else. While many packages in BSD are from somewhere else, much of the "base system" never came from some other maintainer; it's always been BSD.
The base system is sometimes labeled as "minimalist" or "lean and mean" or such things, with the implication that it's maintained the way it is out a desire to have it as small or tight as possible. But that's really not the case; sure, we want it to be all those things, but it's done the way it is because it's really intended to be just what it's called; the base of a system. I've never in my life deployed a BSD system running just what's in base, and I probably never will. I don't know anybody who has. The base just needs to provide the tools to get the system running, and allow you to update it and install other packages. Then you install what you need, for the specific role this system is intended for.
I've been told that the above is more true for FreeBSD than for Net or Open, both of which in many ways have much broader criteria for determining what to include in the base system. As always, you should consult the manuals for the individual systems to determine exactly what goes where.

[ 本帖最后由 盗版青春 于 2008-8-30 13:43 编辑 ]

盗版青春

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 RPM is just a binary package. If you want to auto-install dependencies, 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 the files present. A bunch of black magic happens behind the scenes so that when you run make, it finds and downloads the distribution file from wherever it is, makes any changes or patches necessary, recursively finds and installs all the dependencies, calls GNU configure or imake or whatever preparation programs are necessary with the right options, starts the compile with the right options, etc.

But all those files in that big directory tree are maintained by the FreeBSD project itself. When somebody wrote KDE, for instance, it didn't magically appear in ports trees everywhere. Somebody had to write all the necessary "glue" to build a port for it, then commit the files into the FreeBSD CVS repository so it would be in the ports collection. So again, there's some level of assurance that it works with other things in the ports collection. Any dependencies it has will be there, because it can't declare a dependency on something not in ports.

Things break, of course. Maybe a dependency will have its main site disappear, so nobody can download the source file and start to install it. Maybe a new version of some third program will break a program, which will keep other things that depend on it from working. So of course it doesn't solve all the problems. But the incidence of "I want A, which requires B, which I can't find" is a lot less than it is with such essentially decentralized systems like RPM's turn out to be.

For more detailed information (as always), see the section in the handbook about ports.

Release it!
Now we've got a working understanding of the dichotomy between the 'base system' and the 'ports tree', which I think really trips a lot of Linux users up. Let's talk a bit about releases and upgrading.

Release Engineering
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. Somewhere in mid-2.4 days 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.

Note: There's been some contention about the last paragraph. While many developers have used CVS for parts of the kernel, available information says that Linus never used it for the kernel, thus the whole thing wasn't in a coherent version control system until the move to Bitkeeper. See this paper for details.

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 "robust", it isn't always. The term "stable" refers more to the fact that the codebase itself doesn't have major changes made to it.

In the Linux world, Debian does a similar thing with their release engineering. They have a "stable" release , which mostly only gets major bugfixes. This is roughly the same as a FreeBSD -RELEASE. Then, they have a "testing" release, which gets more in the way of new features, but only after they've been tested for a while and don't seem to have any major problems. This is similar to FreeBSD's -STABLE branch. And, they have an "unstable" release, which is where new development happens, new features are developed, and new versions of packages come in. This, then, corresponds to FreeBSD's -CURRENT branch. (Note: I don't really know Debian's release process that well; this is my understanding of it, which could be completely wrong. Hopefully, someone will send me correct info if I am.)

I repeat, because it's important; these are BRANCHES. Not releases. Branches. They're not points; they're constant streams of development, changing from day to day and hour to hour and often minute to minute. If I grab -STABLE now, and -STABLE tomorrow, they'll likely be different. However, because it's under revision control, I can say something like "Give me -STABLE as of 11:30pm on October 13th, 2003", and always get the same code back.

In fact, that's all a release is; a snapshot at some point along a branch. For instance, what we call "2.2.6-RELEASE" is actually just a snapshot of what the 2.2-STABLE branch looked like on March 24, 1998. On March 25, it was called "2.2.6-STABLE", even though practically nothing had changed. And it kept being called "2.2.6-STABLE" until July 21, when a new snapshot was called "2.2.7-RELEASE". And so on, down the line.

Now, you'll note that there's numbering on these branches too. We've got 2.1-STABLE, and 2.2-STABLE, and 3-STABLE, and 4-STABLE. To understand that, we'll look at where these branches come from. At one point, there was 3-CURRENT. In CVS terms, that was the HEAD of the tree; not a branch, but the main line. Eventually, there was a time when it was decided to start making this branch production-ready, so a tag was laid declaring a certain point as "3.0-RELEASE". At that time, the 3-branch was still -CURRENT; 2.2 was -STABLE. As we approached 3.1-RELEASE, it was decided that it was time to create the 3-STABLE branch. So, a branch was created and called "3-STABLE", and -CURRENT was renamed to "4-CURRENT".

The same thing occured (roughly) when 4 became -STABLE and -CURRENT became 5, and the same will happen again when 5 becomes -STABLE and -CURRENT moves on to 6. Sometimes only the x.0 release is cut before the branch becomes -STABLE, sometimes .1 and even .2 are. 5.0-RELEASE is a snapshot of 5-CURRENT. So's 5.1-RELEASE. So's 5.2-RELEASE. At the current time, the plan is for 5.3-RELEASE to be the first -RELEASE off the to-be-created 5-STABLE branch, though that may change. All depends on the state of the tree.

You'll note, of course, that even though 4.x or 4-STABLE is still (for the moment) the "production" stream, that 3-STABLE still exists (though it hasn't gotten any changes in a long time). For that matter, 2.2-STABLE and 2.1-STABLE are still around too, though they haven't gotten any changes in even longer. Conventionally, -STABLE without a number, then, refers to the latest -STABLE branch. Really, the only time there's any confusion is when a new branch has just been created, so a lot of people are still on the old one. And then you can just use the number to make it unambiguous.

Also, note that 5.1-RELEASE happened before 4.9-RELEASE. And 5.0-RELEASE was before 4.8-RELEASE. This is the time, when one branch is in its ending days, and another branch is in its starting days, when things get really confusing. It's then that the -CURRENT and -STABLE difference comes into place. To make a very rough analogy, 5-CURRENT is like Linux 2.5, while 4-STABLE is like Linux 2.4. But, before that, 4-CURRENT was like Linux 2.3, and in the future, 5-STABLE will be like Linux 2.6. It's not a perfect analogy, of course, partly because we're talking about the full system with all its pieces, not just the kernel. But it's close enough to get the idea.

So. What does that all mean? Not much, perhaps. But, with that background, perhaps you can get a better feel for what happens when, and what the branch names and release numbers mean.

Some more information on -CURRENT vs -STABLE is available in the FreeBSD handbook. There's also an article in the documentation about the release engineering process.

Releases get old
So, now you have a better understanding of where releases come from, and what this -CURRENT and -STABLE nonsense is about. But all releases get old eventually, and need to be brought up to date. So, let's move on to upgrading.

啊泰

谁能给翻译下 什么时候的文章?

ppabc

http://www.over-yonder.net/ 〜 fullermd/rants/bsd4linux/bsd4linux1.php


这是什么？我运行的FreeBSD对我的计算机。我的很多朋友运行Linux ，或至少有一个分布。自然，那么，我们同意Unix风格操作系统是正确的选择，但我们不同意对其中使用。
这是我一直的印象是， BSD的社区的（ y ，每小时） ，一般来说， Linux的了解，远胜于在Linux社区的（ y ，每小时）了解BSD的。我有一个数的理论，这是为什么，但这不是真的有关。我想了很多Linux的人先关掉BSD的，因为他们没有真正了解如何以及为什么它的放在一起。因此，这rant ;作为一个BSD的人，我想尝试解释如何在BSD的工程方式， Linux的人可以吸纳。
虽然有压倒性的之间的相似性的操作系统，在大多数情况下，也有很多分歧。正如你探索更多的分歧，您会发现他们摆脱根深蒂固的分歧。有些分歧，发展的方法，有些超过部署和使用情况，一些关于什么是最重要的，有些是谁的重要，以及一些关于这风味冰淇淋优越。刚才比较，表面上的分歧不告诉你什么，它的更深的分歧，双方解释和理由，为什么每个小组的事情的方式，他们这样做。
什么是不呢？这是不是：

名单指挥correspondances ; “ netstat - rnfinet ' BSD的= ' netstat - rnainet '在Linux上”这类事情。
如何做的所有事情涉及的adminning和运行BSD的方块。
为什么您应该使用的BSD而不是Linux系统。
为什么您应该使用Linux的而不是BSD的。
为什么您应该使用BSD的，这不是说， BSD的。
为什么您应该使用的Linux ，这不是认为Linux 。
为什么是正确的BSD和Linux是错误的。
为什么Linux是权利和BSD是错误的。
为什么我是上帝，你应该崇拜我。
我个人，对我来说，相信（很明显） ，我的操作系统的选择是正确的。这就是我。我不是告诉你，你应该相信这一点。了解了事实，起源背后的事实，弥补自己的可恶主意。这就是为什么你有一。
一些初步的thoughtsthere're了很多哲学之间的差距Linux的世界和BSD的世界。并有很多关于它的表达出来。我特别喜欢去的东西，例如：

BSD的是，您得到什么时，一群的Unix黑客坐下来尝试港口一个Unix系统到PC系统。 Linux是您得到什么时，一群电脑黑客坐下来，并尝试写一个Unix系统为PC 。

现在，我想指出， quip ，并不是因为它的某种形式的绝对真理，揭示了，而是因为它给了一个很好的感觉的一些分歧。该bsds ，在一般情况，是十分更喜欢传统unices比Linux是。很多，那是因为他们直接在线的后裔， BSD的由Berkeley ，这是一个直接在网上的后代，原来的AT ＆ T公司的Unix 。类Unix -商标是商标的公开组，和UNIX -该代码是所拥有的上海合作组织，所以不能，其实说是bsds真的是UNIX的（即的这类声明，引发了usl /联合银行诉讼龙腾灯耀庆，在事实上） 。但是，在许多方面， bsds是直接衍生物的传统UNIX 。
这表明通过在很多方面。它显示了在设计该基地的系统和包装插件。它表明，在分割的海量存储。它表明了在很多细节的命令。它表明，在态度和反射和偏见的发展，这是反映在代码中，以及在用户。
BSD的设计。 Linux是增长。也许这只是简洁的方式来形容它，并在可能的最正确的。
满足playersi'll给这里一个快速的介绍和讨论该系统，我将谈论。请注意，历史陈述，是不全面或权威性，并没有尝试已取得了令他们这样做。交易。
unixunix是不是（正）作业系统。
那么，它是和事实并非如此。
在具体使用， UNIX是一个操作系统本来在发达国家晚60的贝尔实验室是由肯汤普森和丹尼斯瑞奇。多年来，自那时以来，它的制定和分发作为一个商业作业系统，以及研究操作系统，由贝尔实验室和副秘书长和usdl和阿提斯和usl和Novell和上海合作组织和其他人谁可以想出了一首字母缩写词。
它的大概不会太多夸张地说， UNIX是单一最有影响力的作业系统在现代计算。每一个一般用途的电脑设备你会发现，很多特定用途计算设备，将使用的思想和观念，往往从一些代码在Unix的家谱。
当我们用字的UNIX ' ，然后，我们到目前为止，更经常地是指一般的形式，较具体的操作系统进行名称的UNIX ™ 。一般形式是指“任何作业系统，在设计和执行，以及界面和一般的味道，是大致相同的Unix系统” 。这意味着所有bsds ， linuxen ， sunos ， tru64 ，上海合作组织， irix ， AIX操作系统，惠普/ UX的，和演员数百或数千他人。
我不感兴趣，在进入语义讨论如何许多天使的舞蹈就可以元首分裂的头发。让这就够了，当我使用的词组如“ UNIX系统” ，我的意思是，正是你认为当我使用这句话。 pedantry城市是--- >这样的。
linuxlinux也意味着几件事。它的内核，本来写的林纳斯托瓦兹时，他是一个学生在芬兰。自那时以来，它的被殴打，打了约，扭曲， poked ， prodded ， manged ，消化，随地吐痰，踩，嚼起来，抛出了，带来的，否则操纵（不一定是在这一秩序，当然）更多其他人比您就可以轻松计数。
Linux的，也是长远的一个家庭的操作系统。虽然有迷人的形而上的讨论正在发生的数十名世界各地在这个非常秒（我保证它）有关如何“ Linux是没有真正的操作系统，这只是一个内核” ，或“它应被称为'的GNU / Linux的“ ，或类似的话题，我还去整齐地避免这种语义cesspool 。当我说“ Linux的” ，我的意思是Red Hat的职位。我的意思是Slackware的。我的意思是mandrake 。我的意思是Debian的。我的意思的SuSE 。我的意思是Gentoo的。我的意思是每一个2 kadzillion分布在那里，根据周围的Linux内核与实质上类似的userlands ，大多是基于GNU工具，即是浮动周围醚。
bsdbsd主张“伯克利软件分发” 。本来，这是一套补丁和额外添加对公用事业为官方钟UNIX系统被发达国家所csrg在加州大学伯克利分校。随着时间的推移，它演变为改变和/或取代，越来越多的制度，直到在一些未定义点，成为基本上是自己开发的OS ，仅仅发生在分享大块的代码与贝尔的UNIX系统。
当然，它仍需要您有一个钟的许可使用该系统，因为很多这仍是钟的代码。所有的程式码撰写的大学柏克莱分校，不过，发表在什么的来被称为该BSD授权，基本上转化为“为所欲为地狱您想要与代码，只要给我们的信贷写作” 。和很多BSD的代码结束了其工作的方式回复到“官方” Unix系统太，在系统三和系统五，很多都株，他们的工作方式，到各商业叉子的Unix 。
后csrg （大多）解散和停止发展的BSD系统，几个小组到过不同的方式与代码。其中之一是该386bsd项目，该项目采取了BSD的代码，并使它运行在Intel的I386平台。作为386bsd项目的伤口，两个主要群体了386bsd代码往前走，与它;之一，是FreeBSD的项目，其他是NetBSD的项目。在稍后下跌的道路，一些内部的分歧与NetBSD的项目，造成项目为openbsd分裂脱离它。
当我说“的BSD ” ，然后，我的意思是很多事情。我的意思是一般的BSD风味和方法系统。一般来说，我的意思是上述典型的3目前免费提供的BSD系统：

FreeBSD的原定得到最佳的表现，可能就386平台。最近，它的扩大到其他一些平台，包括Alpha和SPARC的，以及作为继承人的I386 ，英特尔的Itanium ，和AMD的Opteron 。其首要目标是要作为稳健和有效率，尽可能就其各种平台，无论是为服务器和台式机的角色。
NetBSD的目的是在运行于许多平台，尽可能。其目标是成为最便携式操作系统于这个星球，它似乎做了相当中肯的工作。
为openbsd是主要集中在（有些人会说'纯粹' ）对安全和相关主题。紧密集成的安全和可审计性和加密技术和相关的问题是其首要目标。
所有这些目标，当然是互换。每一个BSD的关心及工程安全。每一个BSD的关心和工程业绩。每一个BSD的关心及工程可携性。大量大块的代码共享，该集团。许多开发人员的工作，不止一个制度。
精明的读者会注意到，我不提Mac OS X或其基本层达尔文作为bsds 。当他们的基础上，大多是BSD的基础上，上层OS X的是纯苹果。运行OS X ，作为一个使用者，您通常使用它一样的MacOS ，而不是作为BSD的。因此，尽管一些，这可能是适用于在学术上到OS X ，这是没有任何的实用价值的理解。达尔文是接近一个标准的BSD的感觉，但其大多数userbase是人谁是来自BSD的，所以这是一个位范围以外的这篇文章，以及。大部分的一般资料，不过，可能会转移容易。
当我们讨论的具体内容，在这篇文章，我将大多是指FreeBSD的，因为这是一个我个人来说，上午，到目前为止，最熟悉的。对非常具体的点，将有显着性差异。更普遍的一点，越有可能是要同整个集团。哲学，所有bsds十分相似，在对比了Linux的方法。和总之，哲学是什么这篇文章的约摆在首位。
该基地systemthe的概念， “基地系统”是，我认为，原因是最麻烦的人用Linux的方法。这是完全可以理解的，因为整个的想法只是甚至不存在，在Linux的世界。
Linux的，从一开始，只是一个内核。没有进入永恒的辩论，什么“作业系统”正是构成的，人们很容易的国家，一个内核本身并不是非常有用。你需要的所有userland事业，使其工作。 Linux的一直是砾岩;内核从这里，一个律师从那里，一个常任从这个其他地方， Vim中，的Perl ， gzip ，焦油，并捆绑他人。
Linux的从未有过任何形式的区分什么是“基地制度”和什么是“ addon事业” 。整个系统是“ addon事业” 。 MySQL的没有什么不同，从康乐事务由KDE的从的WHOIS从DC从gnucash从...每个位元的系统只是一个或另一个新增-产品包装上。
相比之下， BSD的一直有一个集中的发展模式。还有的一直是一个实体的“负责人”制度。 BSD的不使用GNU LS型或GNU LIBC的，它使用的BSD的律师和BSD的LIBC的，这是直接的后裔ls的和LIBC的有，在csrg分布式的BSD新闻稿。他们从来没有发展或包装独立。你不能走“下载的BSD LIBC的”某处，因为在BSD的世界， LIBC的本身是没有意义的。律师本身是没有意义的。内核本身是没有意义的。该系统作为一个整体，是一件，而不是一群小件。
现在， x是不是一个部分的FreeBSD的基础系统。它的一addon方案。由于X是没有的一部分，该基地的系统，第十应用程序，这种感觉的xterm和KDE和Gnome和Mozilla浏览器及Gaim和xmms等，显然不能的一部分，该基地的系统。他们添加的包件，这是治疗和思想的不同。主要不同的是，他们正在开发的。
的NetBSD和OpenBSD这样做有一条X执行在基地，因为他们的方式整合，它与他们的控制台的驱动程序。他们都使用大量的修改，非常自定义版本，因此它并不可行，以保持其作为一个单独的软件包。
整个基地系统是共同发展。可以肯定的是，有部分正在该基地的系统一样， Sendmail和约束和tcpdump和ssh等，这是事实，在个别套件这是其他地方的发展。甚至还有一些在GNU软件包一样， groff和海湾合作委员会和gzip等，这将是立即可识别的任何Linux用户。但这些治疗特别是，在这版本的导入树，然后成型，以适应其余的系统。事实上，在他们中的许多以往被BSD的只;约束和Sendmail原本发达伯克利分校的一部分BSD的，只有后来成为单独提供。我的FreeBSD系统的要求运行，海湾合作委员会版本3.2.2在这一刻。在技术上，它不是真的，海湾合作委员会3.2.2 ;这是一个FreeBSD的编译器基于GCC 3.2.2 。该版本的tcpdump我已经在这里得到技术上并不3.7.2 ，这是一个FreeBSD的tcpdump的基础上tcpdump 3.7.2 。
在大多数情况下，当然， FreeBSD的版本几乎是无法区分的从供应商的版本。正在通常有一些改变，编制安装（ makefiles等）让它建立干净与其余的系统，有时一些必要的补丁，使编译和运行的权利。一些变化是更广泛的，有些是巨大的。但是，他们都保持在一起，并被迫发挥很好的合作。有一个基本保证，该件在一个BSD的基地系统所有适合在一起，设计所导致的。
首要原因一对外保持一揽子成为输入和跟踪，在相应的制度是，它是在以某种方式，基本不够系统的运作，它的最简单的有它存在的预设值。在FreeBSD目前使用openssh的SSH服务器和客户端，这是融入相应的制度，因为，在当今这个时代，一个安全的远程接入方法是充分的基础，任何制度，它的实际需要。海湾合作委员会和binutils的一部分，该基地的系统，因为...那么，他们都需要建立相应的制度。 X和Gnome和PostgreSQL数据库和Apache等不属于该基地的系统，而且可能永远不会，因为他们没有获得所需的系统和部署，将不会用于对许多系统，不需要这种紧密结合...原因有很多。
它的重要的是要强调这个“基地制度”的构想，因为它是，我认为，其中一个最明显的迹象显示差异，在发展方法之间的BSD和Linux 。 Linux的分销商可能会放在一起的作品和测试，他们合适的释放出来之前。他们甚至可能有一些个性化的一些软件包。但它的不同，而不是从激烈的排序一体化所做的BSD 。尤其是在这么多的组成部分，基地系统并非来自“其他地方”摆在首位;他们已经住了他们的整个生命作为一个系统的一部分。
一些Linux发行版（ Debian和Gentoo的，从我的理解，是尤为突出该组的成员）更为相似，这个基地/港口的分裂比别人。他们不断的东西一条线之间的什么的，要得到系统的运行，并且所有其他软件包，您可能想要安装的一种制度。与众不同之处是什么，这从BSD的基础，制度是，大部分的这些软件包仍维持在其他地方，和公正的“收集”到Linux的dist 。有没有“参与Gentoo的TFTP ” ，例如，它的一些方案，从别的地方。而在许多软件包在BSD的是来自其他地方，大部分的“基地系统”从来没有来自其他一些维护者，它一直是BSD的。
该基地系统，有时是标示为“最低限度”或“精益和指”或这类事情，言下之意，它的维持方式，这是一个愿望，有它作为小或紧越好。但是，这真的并非如此;肯定的是，我们希望它成为所有这些事情，但它的工作方式，这是因为它的真正用意只是它的所谓;的基础上的制度。我从来没有在我生命中部署了一个BSD的系统运行刚才什么的，在相应的，我可能永远也不会。我不知道任何人谁了。该基地仅需要提供工具让系统运行，并允许您更新和安装其它软件包。然后安装了您所需要的，对于特定的角色，这个制度主要是为。
我一直在说，以上是真正的为更多的FreeBSD超过净或打开，这两项研究在许多方面有更广泛的准则，以决定如何处理，包括在基地系统。与往常一样，您应该谘询手册，为个别系统，以确定究竟哪里。

ppabc

港口系统
然后，有第二类;这些程序是添加对软件包。在BSD的世界，这是通常所谓的“港口系统” 。该名称是选择一个具体的理由。

传统上，当您想运行的一揽子在您的系统上，第一件事，你不得不这样做是编译它。而且往往之前，你可以编译它，您必须反复折腾它。您的系统将需要不同的头文件。有时，体现常数会有所不同。有时，您甚至需要重写部分，它从无到有，因为基本假设没有举行对您的系统。

或者，换句话说，您必须“端口”到您的操作系统，和/或您的具体制度。基本法的原意的港口体系，就是要做好所有的“移植”的东西给你。它也自动化建设和安装，并提供包装服务（的事情，像'卸载' ）是不是很好地反映在名称。

但由于与很多事情，它的增长，过去它的名字变成野兽，这是今天。目前FreeBSD的港口收集已接近一万包在它（这个数目，当然会过时，很快，但对发展的本质） 。最明显的特点，港口是它建立的东西，从源代码的所有时间，而不是只安装预先建立的二进制文件。这，似乎是另一个之一，那些赤裸裸的分歧，这一趟的人时，试图看看BSD的，从一个Linux的角度来看。它建立了从源头只是一个副作用，这不是主要目的，或差异。二进制软件包也可;事实上，二进制软件包是建立在从港口树！

现在，它的真实，大多数Linux用户安装的二进制软件包，以及最BSD的用户安装，建立从源头。部分，这是一个结果的工具;港口系统的设计是围绕建设的概念，从源头，与有能力作出并安装二进制包被的东西一事后，而Linux的包装一样，每分钟转速和dpkg和这样的设计，围绕的概念，安装一个二进制软件包，与建设从源头作为一种事后的。一些，这是历史;二元包装在历史上并不是一个突出的主题，在UNIX系统，正如我刚才所说。为此事，包装本身就是一个较近期的事。传统上，您要处理与卸载等手动。

Gentoo是一种Linux发行获得在突出这些天。它的一个大卖点是它的搬运系统，这是往往被视为非常类似BSD的港口。也许最明显的，因为它从源代码编译。避免了很多问题的二进制软件包。我从来没有用它自己，但展示我已经得到了从信息，我看到了它，和我认识的人谁使用它，是因为它的采取了一些很好的意见，从每一个人，和他们一起smooshed 。它会很有趣，看它如何进步和成熟，在未来几年中。它的还有很多更多的Linux比BSD的，但它可能是最接近的BSD风格的主要Linux分发。

现在，有优势，以预编译的二进制文件;大多时间（如在少得多） ，而且通常它会采取很多较少的空间，安装预编译的包，会比以编制方案。也有一些优势，建设从源头一样，避免各种版本图书馆丑（我个人的宠物peeve与二进制软件包） 。您可以安装的二进制软件包在Linux或BSD的;您可以建立从源头上Linux或BSD的。但用户似乎是偏颇的不同，因为系统是偏颇的不同，因为使用者是偏颇的不同...这一切配合。

我猜想什么是最重要的是要认识到，之间的差别港口和每分钟转速的不只是港口汇编和每分钟转速的正义安装。港口设计，以涵盖全系列的零碎安装的东西;编码和跟踪和安装的相依性，包装，安装及deinstalling ，当地的变化，需要建立在您的系统，编译时的配置的调整...所有这些事情。 1 RPM的只是一个二进制软件包。如果您想要自动安装的相依性，你必须有更高水平的工具一样， urpmi或apt - get这样做。而且，由于它的二进制，你必须处理图书馆的版本冲突，或失踪的编译选项，或任何其他限制，您所没有建设自己的系统。

此外，港口一样，其余的BSD的系统，集中。 “港口树” ，实在只是一个大目录树与一群分类目录，各载有1 Makefile中的一些变量的定义，校验和文件，包装清单，以及其他各种可能的事情。每个这些目录代表一个单一的计划，这是所描述的档案。一群黑色魔术发生在幕后，所以，当你运行make ，它发现并下载档案，由分布在何处，这是使任何改变或修补程式的必要，递认定，并安装所有的相依性，要求在GNU配置或imake或什么编写程序是必要的与正确的选择，开始编译与选择的权利，等等。

但所有这些文件在大目录树是由FreeBSD的项目本身。当有人写了KDE的时候，例如，它没有神奇地出现在港口的树木，无处不在。有人曾写一切必要的“胶水” ，以建立一个港口，然后承诺文件到FreeBSD的CVS仓库，所以将在港口收集。再次，有某种程度的保证，它与其他的东西，在港口收集。任何相依它将会在那里，因为它无法申报依赖的东西不是在港口。

打破东西，当然。也许依赖将有它的主要网站的消失，所以没有人可以下载源文件，并开始进行安装。也许新版本的某些第三方程序将打破计划，该计划将继续其他的事情，依赖它的工作。因此，当然这并不解决所有问题。但发病率“我想，这需要b ，我无法找到”是一个大大少于它是与这种基本上是分散的系统一样，每分钟转速的转出。

为更详细的资料（一如往常） ，看到一节中的手册约港口。

它释放！
现在我们提供了工作的认识二分法之间的'基地系统』和『港口树' ，而我觉得真正的知识产权了很多Linux用户。让我们谈点新闻稿和升级。

新闻稿工程
该bsds所有使系统控制下的修订;所有免费bsds使用个人简历。修订管制（在极简短的）是一个过程，其中编辑程序的手段检查出来的档案或一组文件，使更改，然后检查在新的版本，随着一个信息，描述的变化。全面的历史，所有的变化是存放在修订控制系统，使您可以查看更改的历史记录，选中了一个旧版本，看看之间的分歧任意版本等。

所有bsds提供公众查阅他们的个人简历存放在一种或另一种方式;普遍通过匿名CVS ，或cvsup结帐或镜像，或常常都。这意味着，作为一个使用者，您可以确实看到什么样的变化发生时，谁没有他们，他们为什么没有他们。您也可以始终让您的手中，就最新的变化（几个小时的时间，无论如何，这取决于镜像战略） 。所有的免费bsds有邮件列表，您可以订阅和看到的变化，因为他们正在作出的。事实上，他们都有的Web前端以及;您可以戳左右的FreeBSD的整个源代码树在网上http://cvsweb.freebsd.org/src/ ，看到所有的历史，每一个文件。

Linux的，从历史上看，没有使用任何版本控制为核心。某处在中2.4天内核开始被保存在一个公共bitkeeper存放。许多其他公用设施使用版本控制，但由于他们都是分开发展，不存在任何中央地方你可以去看看，通过改变。因此，有时很难找到一个历史性的图片，甚至任何一个部分;这样做对于整个分布实际上是不可能的。

注意：有一些争论约的最后一段。虽然许多发展商有使用CVS的部分内核，现有的资料说，莱纳斯从未使用过它为内核，因此，整个事情不是在一个连贯的版本控制系统，直到搬迁到bitkeeper 。看到这个文件的细节。

这导致了很多的分歧。在一个非常真实的意义上说， BSD的系统中不断发展，我可以随时更新，我的系统中，以绝对的最新代码，不论“新闻稿” 。在Linux ，这并不真的拥有尽可能多的含义，因为释放的过程中是非常不同的。我认为最适当的动词为Linux的版本是“组装” 。 Linux的释放是组装从版本抗体这一计划，再加上版本的CD这一计划，再加上英法版本，这个计划的...所有同版本的XYZ的Linux内核。在BSD的，不过，由于件都是共同发展，动词“一刀切” ，使很多更有意义;释放的是“一刀切”在某一个时间。

Linux的发行内核在两条平行线（好，往往多于2 ，但我们正在简化） ;版本与奇数轻微释放的人数，作为一个“发展”的版本，一个版本一个，甚至轻微的版本编号，作为一个“生产”版本。该bsds也有“发展”和“生产”的轨道，但他们正在处理的，而不是不同的看法。

个人简历，最喜欢版本控制系统，已“的概念党支部” 。很容易理解，但有点难以解释。基本上，当您在“分行”的一个文件或一组文件（或整个目录树） ，您可以创建一个新版本的文件，该文件存在于同向平行的主要版本。当您更改的主要版本，它不会影响分支版本。和您可以更改该分支版本，在不影响小学。

在FreeBSD上，还有的通常为2积极发展线;之一，所谓的“电流” ，这是发展的版本，和其他所谓的“稳定” ，这是生产的版本。双方的，当然是正在发展，双方有一些企图作出让他们使用。 -稳定，作为一项规则，得到的错误和安全补丁，但只获得新的功能和等是行之有效的，通常是由一个不惜在电流第一。 -目前获得新的功能，大建筑的变化，所有这些各式各样的新的发展的东西。应该指出的是，命名的分行并不一定意味着什么，似乎;而稳定的，通常是“稳定”作为在“稳健” ，它并非始终。而言， “稳定”是指更多的事实，即代码本身也没有重大变化，向它提出的。

在Linux的世界里， Debian是否有类似的事，与他们释放工程。他们有一个“稳定”释放，其中大多只获得重大错误修正。这是大致相同，作为一个FreeBSD的释放。然后，他们有一个“测试”释放，获得更多的方式的新特点，但只有后，他们已经测试了一段时间，不似有任何重大问题。这是类似的FreeBSD的稳定科。和，他们有一个“不稳定”的释放，这是哪里发生新的发展，一些新的功能开发，以及新版本的软件包进来这一点，那么，对应到FreeBSD上的电流科。 （注：我真的不知道Debian的释放的过程，以及这是我对资讯科技的认识，这可能是完全错误的，希望会有人给我正确的信息，如果我） 。

我再说一遍，因为它的重要，这是党支部。没有新闻稿。分行。他们不点;他们正在不断流的发展，改变每天和每小时，而且往往分钟到分钟。如果我抓稳定，现在，和稳定的明天，他们将可能会有所不同。不过，因为它的控制下的修订，我可以说，像“给我稳定，截至下午11点30分就2003年10月13日” ，始终得到相同的代码回。

事实上，那的所有释放的是;快照在一些点的一个分支。举例来说，我们称之为“ 2.2.6释放” ，其实只是一个快照，什么2.2的稳定版本分支看上去像3月24日， 1998年。 3月25日，它被称为“ 2.2.6稳定” ，即使几乎没有任何改变。它不断被称为“ 2.2.6稳定” ，直到7月21日，当一个新的快照被称为“ 2.2.7释放” 。等，下跌的路线。

现在，您会注意到，有的电话号码就这些分行。我们已经获得2.1稳定， 2.2稳定， 3 -稳定， 4 -稳定。要明白，我们将看看这些分行从何而来。在这一点上，有3 -电流。在cvs中的条款，这是头部的树;不是一个科，但主线。最终，曾经有一段时间，当它决定开始做这个分支生产就绪，所以标记奠定了申报的某一点为“ 3.0版本” 。在那个时间， 3科仍然是电流; 2.2是稳定。正如我们接近3.1释放，这是决定，这是时间创造3 -稳定的分行。因此，分行已创建和所谓的“三稳定” ，和目前已重新命名为“ 4 -当前” 。

同样的事情发生了（大约）时，四成为稳定和电流，成为五，同时将再次出现时，五，成为稳定和电流动作，至6条。有时只有x.0释放是削减之前，科成为稳定，有时0.1 ，甚至0.2顷。 5.0释放是一个快照5电流。所以的5.1释放。所以的5.2释放。在目前的时间，该计划是为5.3释放能够成为第一释放小康要被创造的5 -稳定的分行，尽管这可能会改变。一切取决于该国树。

您注意，当然，即使4.x或4 -稳定仍是（目前） “生产”流，即3 -稳定仍然存在（虽然它没有得到任何的变化，在一个很长时间） 。为此事， 2.2和2.1稳定的稳定仍然是过于靠近，虽然他们没有得到任何的变化，甚至更长的时间。传统上，稳定没有一个号码，然后，是指以最新的稳定版本分支。真的，只有时间有任何混淆，是当一个新的科刚刚创造的，所以有很多人仍然对旧1 。然后您可以只使用人数使其毫不含糊的。

此外，请注意5月1日释放前发生4.9释放。和5.0释放前4.8释放。这是时间，当一间分行，是在其结束的日子，和另一科是在其开始的日子，当得到的东西，真的混乱。它的，然后说，电流和稳定的差异生效。作出一个非常粗略的比喻， 5 -目前是一样的Linux 2.5 ，而4 -稳定是一样的Linux 2.4 。但是，此之前， 4 -目前是一样的Linux 2.3 ，并在未来的日子， 5 -稳定就会像Linux 2.6的。它不是一个完美的比喻，当然，这部分是由于我们正在谈论的完整的系统，同所有作品，而不只是内核。但它的亲密足以让这一想法。

因此。这代表了什么，所有意思呢？没有太大的，也许。但是，随着在这一背景下，或许您可以得到较好的感受时会发生什么，和什么科的姓名和释放号码的意思。

一些更多信息，对电流与稳定，可在FreeBSD的手册。也有一篇文章，在文件中关于释放的工程进程。

新闻稿得到岁
所以，现在，您有更深入的了解那里的新闻稿从何而来，以及是什么，这电流和稳定是无稽之谈。但所有的新闻稿得到最终岁，需要加以带来的切合时宜。因此，让的举动对提升。

lsstarboy

感觉翻译的那篇，和ipfw原来的那个中文man差不多，比看英文的还累，基本上是越看越糊涂。

xpban2006

嗯同感

qishking

google翻译有待加强

bestwc

月经贴。。。标题党。。。又被骗进来。。。

咱没想和Linux叫板可为啥总有人不经过我同意就代表我跟Linux叫板？

盗版青春

原帖由 bestwc 于 2008-8-31 01:10 发表
月经贴。。。标题党。。。又被骗进来。。。

咱没想和Linux叫板可为啥总有人不经过我同意就代表我跟Linux叫板？

同是UNIX-like操作系统，难免有人把它们在一起比较．