Iarasi despre FreeBSD si Linux (in engleza)

We've all heard the age old argument second only to the vi vs. emacs religious wars: FreeBSD Vs Linux. As a long time linux user, I decided that is was time I spent some time on the other side of the fence to see if it was any greener. Oh, and by the way, vi rules. Background My first experience with Linux was about 7 years ago. I decided to try Linux after a failed attempt to install SCO Unix (eek... really dodged a bullet there). I started with Slackware and over the years I migrated through various other distributions before finally settling down with Gentoo. I have been using Linux as my main OS for about 2 or 3 years. With my background, I felt reasonably confident that I could adapt well to a different unix like operating system. I prefer the BSD license to the GPL, so I saw some potential philosophical advantage in using BSD. For my evaluation, I chose FreeBSD because after a cursory glance, it appeared to have the best hardware support and appeared to be the most popular. Hardware The machine I used was my "second in command" machine. It was retired from active duty almost a year ago, so it is rather old, but hasn't hit the stage of seeming painfully slow. Here are the specs:1Ghz Athlon ThunderbirdFIC AZ11 motherboard with a messed up secondary IDE controller(it works if I hit reset after powering on)640Mb PC133 SDRAMGeneric 64Mb Geforce 2 MX400 (with rather blurry 2d graphics)Sound Blaster LiveCreative 5x dvdrom with dxr2Mitsumi 4x4x24 CDRWTulip based Linksys ethernet cardAt this time, I would like to advise all of you girls and boys thinking about building your own system to BUY NAMEBRAND PARTS. You might save a few dollars, but there really is a difference in quality. Installation I grabbed the ISOs for FreeBSD 4.8 because it was the most recent stable revision at the time I started. I won't bore you with all of the gory detail of the install. It uses a curses based installation program which should be reasonably comfortable to anybody who has installed Slackware. I made a few mistakes and had to restart a couple of times since you can't always easily back up in the process. Once I finally got the process down, I had a working console system within an hour (I chose to delay installing X until later). Configuration Most of the hardware worked without any intervention on my part. The sound card required building a custom kernel, but the kernel building process is well documented and rather painless (roughly on par with building the kernel in linux). Instead of using something like "make menuconfig" under Linux, you edit a moderately sized config file and use it to generate the build parameters. I just had to add the line "device pcm" to the config file, build a new kernel and reboot. BAM! The sound was working. No need to muck with modules or setup aliases or any of that other junk that I frequently forget. I then used ports to install X and also to install the nvidia driver. I noticed some problems with KDE applications dumping core on exit and discovered that it was a problem related to the stock 4.8 kernel and the nvidia drivers. After a few minutes of searching on bsdforums.org, I discovered that there was a kernel patch to fix the problems. The patching process and rebuild of the kernel went off without a hitch. Ports and Packages My main interest in investigating BSD was the ports system. As a Gentoo Linux user, I have often heard portage compared to ports. After observing a number of similarities in file layout of ports and portage, I have no doubt that portage was inspired by ports. To install a port, you find the corresponding directory under /usr/ports and enter "make install". I found this to be a bit of hassle compared to portage largely due to having to find the appropriate directory which is not always found in what I would consider a logical location (for instance the nvidia driver is in /usr/ports/x11/nvidia_driver). I later found out that I could use the command "whereis" to locate the correct directory. This is very useful since it finds the location much quicker than running "find" from /usr/ports. For the most part, the ports I installed worked quite well and correctly handled dependencies. There were some minor annoyances such as the openoffice port prompting for user interaction partway through the build process. I was not pleased to get up in the morning and discover that the build was not completed. One advantage of using a port compared to an ebuild is that it you need to kill the build partway through, you can later resume where you left off (there may be a way to due this in portage, but if there is, it is not very obvious). After you have installed a port, you can use "make deinstall" to remove it, however there is a bit of a snag. If you use "make clean" to avoid wasting disk space, "make deinstall" will not work. You must unistall the port as if the program was installed as a package. I found this annoying since I am only interested in installing from source and I did not want to waste my time learning about the package system (used for installing binary packages). Many ports have options that you can pass to the make command in order to enable options, but these have to be dealt with on a port by port basis and not set globally like portage's USE flags. There is a method to globally change the CFLAGS used by ports, but I never bothered to learn it (I trust the defaults). I noticed a number of things which made ports appear to be more release-oriented than the portage system. The first is that there is no way to upgrade the ports tree without installing an additional port after installation (namely cvsup). I installed cvsup and noticed that I had to modify a config file before I could use it. Example config files were included, but they needed minor alterations before they could be used (mostly just setting the server name). This isn't necessarily bad, but the documentation is extremely thorough and not geared toward newbies. Once configured, it is relatively painless to upgrade the ports tree. Similarly, upgrading an installed port to a newer version is a bit clunky without installing another utility (namely portupgrade). It isn't a big deal, it just leaves me with the impression that the developers expect some people to treat different releases as distinct entities much like many binary Linux distributions. Of course, it is still possible to do a continuous upgrade like I would with Gentoo. Release 4.9 was released in the middle of my evaluation period, and I successfully upgraded the system and kernel to the new version without reinstalling. Overall, the system seems to work well, in spite of some rough edges. Conclusion Overall, I found FreeBSD to be a very usable system, but not very newbie friendly. The documentation was generally good, but it could benefit from some additional documentation geared toward beginners. I had to adapt a bit to the command line utilities since some of the parameters are a bit different from the equivalent GNU versions. For instance, "find" requires that the directory be specified whereas with the GNU version, it can be omitted. I also discovered that under BSD, it is bad to edit /etc/passwd directly. I tried to change my shell by editing /etc/passwd, but it seemed to be ignoring it. However, if I used "vipw" as root, I could edit it without any problems. I suspect that the system examines some sort of cached copy of the data in /etc/passwd, so any changes not reflected in the cache are not seen. There is also a handy too "chsh" which will allow any user to change his own default shell. I was a bit disappointed with the ports system, however it is still quite useful. To be fair, I am not currently aware of any package management systems that actually satisfy me (*shameless plug* I am working on a new package management system, and when it is more developed I suspect many people will like it). I did not do extensive performance testing, but X seems more responsive under FreeBSD than it does under Linux, particularly when running CPU intensive tasks in the background. Overall, I would say that FreeBSD is not good for Joe (L)User, but it is definitely worth consideration by hard-core techies. My first few nights using it were rather painful, but within a week I was becoming reasonably comfortable. If you think you are up to it, I would recommend giving it a try, just don't give up too quickly. About the authorGabe Yoder is a full-time software engineer and a geek's geek. In spite of work, he enjoys programming and is one the OpenBeos development team. When not chained to the computer, he enjoys collecting swords and shooting people with paintballs.