榆树网 » 比较

浅谈FreeBSD与OpenBSD

admin — Mon, 04 Jan 2010 05:52:31 +0000

最近对FreeBSD的升级和安装进行了一些了解，同时也试着在OpenBSD找寻相同的方法，于是就有这篇文章啦；本文不注重详细比较FreeBSD和OpenBSD的区别，只是记录一下我所涉及的一些功能。

1、安装

FreeBSD在安装方面较OpenBSD强不少，FreeBSD大部分安装界面都是“图形”的，一般说来只需空格回车 + 光标就可以搞定所有的操作;而OpenBSD就不一样了，在很多情况下都是通过键盘输入来选择相应的选项，在磁盘分区的时候更不智能。

2、升级

FreeBSD:

FreeBSD在升级方面相对比较全面，对于系统本身，可以使用freebsd-update（似乎6.x以上的版本才有）进行升级，如果官方release补丁，可以通过freebsd-update直接将系统更新最新补丁。同时FreeBSD可以通过freebsd-update进行跨版本升级，例如将系统从7.x升级到8.0-RELEASE，FreeBSD在Release一个版本的时候，会提供相应的升级方法，很方便的。

对于Port的升级，可以通过csup或者是cvsup对ports进行升级，更新ports树之后，运行portupgrade -a对系统已安装的软件进行升级，这个挺方便的，并且ports里面的软件更新频率非常高。

对于爱偷懒的人，比如我，有的时候很烦去编译安装软件，希望直接安装二进制文件。此时pkg_add也提供了相应的功能，只要你知道软件包的名称，可以通过pkg_add -r <软件名>进行安装，如：pkg_add -r screen，程序自动从FreeBSD官方的Mirror站点下载已经编译好的二进制文件。

OpenBSD：

相对FreeBSD而言，OpenBSD在升级方面就逊色了不少，首先系统没有类似freebsd-update的升级工具（至少目前我没有发现，在网上也暂时没有找到相关的文档），在大版本Release的时候，官方也提供相应的升级方法，但是感觉升级方法不如FreeBSD灵活，OpenBSD只是下载安装盘上的那几个.tgz文件，手工解压，做一定的操作之后即可，具体可以参考：http://www.openbsd.org/faq/upgrade46.html，感觉没有FreeBSD方便。

对于Ports升级，系统也没有自带用类似FreeBSD发行版里面的csup程序，需要通过ports安装cvsup来搞定，安装完毕之后需要上官方：http://www.openbsd.org/cvsup.html 自己编写一个cvsup的配置文件，然后对Ports树进行升级，Ports里面的软件包和更新速度较FreeBSD而言也逊色了很多。

OpenBSD Ports里面的软件包也可以安装已经编译好的二进制，参考：http://www.openbsd.org/faq/faq15.html 可以了解到，只需设置一个PKG_PATH变量后，即可通过pkg_add -r screen进行安装，也是蛮方便的，但是软件比较少。如果软件有更新，如何更新（暂时我还不会）。

3、配置

FreeBSD的配置稍微人性化一点，简单的拿ports里面的软件包来说吧，通过ports安装的软件包，一般配置文件都在/usr/local/etc/XXX/下（XXX为软件名称，如apache22等），启动脚本在/usr/local/etc/rc.d/XXX，如果需要开机启动，必须在/etc/rc.conf中增加XXX_enable=YES，都则无法通过程序自带的脚本启动，也无法开机自启动。对于内核参数的一些优化可以通过修改sysctl.conf来搞定，有些必须在载入内核的时候配置的参数，可以通过修改/boot/loader.conf文件来搞定。就可以不用重新编译内核了。

OpenBSD的配置就没有那么人性化啦，对于ports安装的程序，不同的程序的配置文件放置在不同的位置上，需要根据具体的软件来区分，同时启动脚本也不是那么的人性化，安装完ports之后，程序会告诉你如何启动，让你加入到rc.conf.local中即可。对于内核参数，如果无法在sysctl.conf中进行修改，似乎必须通过编译内核来实现，OpenBSD似乎不支持loader.conf这种在启动前优化内核参数。

4、文档

FreeBSD官方的文档比OpenBSD官方的文档全面，并且也比较容易找。

以上纯属个人观点，欢迎拍砖。

Subversion or Git

admin — Mon, 28 Dec 2009 01:21:38 +0000

There’s been a lot of ambient (and not so ambient) noise in the geeky corners where I often linger about Git. There seems to be some sort of mass exodus underway as folks indicate that they have, or are planning to, move away from Subversion for their source control needs and I have to admit that I’m feeling a little ignorant.

I haven’t used Git (yet?), but I’ve been doing some reading and I still don’t quite understand the infatuation. Don’t get me wrong, it looks like there are some nice features, but at what cost?

The key difference between the two systems seems to be the model itself. Where Subversion offers a centralized model, Git provides a decentralized model. At the risk of over simplification, this means that Git offers each developer their very own, fully autonomous copy of the entire repository. With Subversion, each developer has their own working copy, but commits changes to a single, central repository.

The arguments in favor of the decentralized approach, as I understand them, include:

Speed

Okay, I like speed. Since each developer has a local copy of the entire repository, fundamental actions like diff, commit, etc. are all local. That’s always going to be faster. Fast is good.

That said, server interaction with Subversion isn’t exactly excessive. Developers work in local working directories and only interact with the server in short bursts. I’ve never found myself thinking, “Great Scott, this is unbearably slow.” For me, at least, this seems like a fix for something that isn’t broken.

Smaller Space Requirement

A Subversion working directory contains two copies of the entire code base. One that is actually being worked on and another tucked away in the .svn directory. I remember reading somewhere that the Mozilla repository required ~12Gb of storage in Subversion and ~420Mb in Git.

This is a substantial difference, to be sure, but there’s a phrase that everyone in technology hears on a daily basis: storage is cheap. That can’t be a compelling argument for one problem and not for another, so I don’t think this difference is one that’s going to precipitate a switch all by itself.

Line Ending Conversion

This is an important factor for mixed environment teams. Evidently early versions of Git made no changes and more recent version handle the conversion automatically. That decisioning is manual with Subversion, but is spectacularly easy to do by making a simple change to ~/.subversion/config for each file extension impacted to specify the line ending desired:

*.sh = svn:eol-style=LF;

Other Concerns

In addition to the fact that none of the arguments presented in favor of Git are particularly compelling to me, at least not the way I understand them, I have a few other concerns about the decentralized model. Actually, they probably all roll up to a single concern – accountability.

Every project I’ve worked on requires some level of immediate or semi-immediate accountability. A project manager who needs to ensure that an appropriate amount of progress has been made against the project plan, a boss who needs to spot review code or maybe a continuous integration process that needs regular repository updates so that its not just rebuilding the same old thing.

It seems like the decentralization of the repository would hamper those efforts. Sure, it can be done, but it would have to be done with process.

I also wonder if, in a team environment, having too many people doing too much of their own thing for intervals that stretch too long would make effective merges all but impossible. It seems like it would.

Am I missing something? Are there additional benefits? Is there anything else I haven’t even mentioned that I should be considering? I’d love to hear from other source control users who have moved to Git from Subversion.

From: http://robwilkerson.org/2008/04/05/subversion-or-git/