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.

盗版青春

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

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

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