Slashdot Mirror
Very Non-Biased FreeBSD Review
Anonymous Coward writes "From daily.daemonnews.org we have a link to a very very good
article
that describes almost exactly why many people (including myself) use FreeBSD." The author makes some good points, including good uses for file attributes and secure levels. An argument for BSD for several specific uses, and Linux for others.
It can _easily_ be configured to provide a serial console. It requires changing about 3 lines in config files and running lilo. Most Sparc distributions allow you to install and run direct from a serial console by simply typing
boot fd(0,0,0) linux serial
at the firmware prompt.
Engineering and the Ultimate
This article was interesting and made some good points about security levels and the robustness of UFS, but:
/proc is hardly a big CPU overhead to generate and parse (the real criticism is that it's a mess, combining process and config/status info)
/etc/sysconf file structure does make sense once you get past the initial proliferation of files. Like the /etc/rc* structures, this is largely a matter of taste.
-
- lilo supports booting from serial, just like FreeBSD. Creating a boot disk is the standard way to avoid getting locked out of your system when you create a new kernel, although the FreeBSD bootloader feature mentioned sounds nice.
- linuxconf is a boon to those who are not Linux/Unix gurus, and the Red Hat
I'm probably biased towards Linux, since I use that most, but I've used a lot of BSD and other Unix systems, including OpenBSD. But at least I don't claim to be 'very non-biased'!
Even with the giant lock you'll get more out of that second CPU than you might think. My 2x550MHz will do a "make -j 3 buildworld" in 60% of the time with the second CPU enabled (58 minutes) compared to one CPU (97 minutes).
Yes, the GL sucks, and the SMPng stuff will (eventually) be great. But depending upon what your load mix is, you can get full use out of your second CPU now.
>> Extra flags like these are also present in ext2
>> supposedly, though I don't see how to set them
>> with chmod in either FreeBSD or Linux
>That's because you can't read a man page. Don't >blame it on GNU/Linux or FreeBSD...
>In GNU/Linux it is 'chattr' for the ext2 file >system.
>In (Net|Open|Free) BSD you use 'chflags' for >UFS/FFS
Thanks for the pointer, but like I said above, I didn't see how to set them with chmod, and no mention of extra flags is in that command's man page, in either OS.
Granted, FreeBSD has a "See Also" section of its chmod man page that refers to 'chflags', but GNU/Linux's man page (in Slackware 7.1) has no such reference. Maybe that's why the author overlooked the extra flags in ext2...incomplete documentation.
I'm sure I'm not the only person who has not found relevant information in an, IMO, relevant place (chmod's man page) and become lost or doubtful. I'm going to see who is in charge of updating GNU chmod's documentation.
OK, I wrote the maintainers of GNU chmod, and they've added a See Also section to its man page. They were really nice, and prompt. Kind of makes arguing about stuff on /. a little silly if you can just change things yourself. I appreciate the new commands, though
[man -k|apropos] flags
doesn't work with Slackware GNU/Linux, the place where it would have maybe been the most useful. The thing to ask about documentation is, why not make it the most useful to anyone who doesn't know how to do something, rather than just a reference to those who already do. Consider this: what command is an average beginning Unix tutorial going to teach first ? 1) chmod 2) chflags 3) chattr . I'll bet that a lot more people know about 1 than do about the other two, because only chmod is a standard between all unixes I know about (which may not be many, but is >1). And all three commands perform a subset of one function - change some of the various flags on a file.
The best way for all of the Unixes out there to improve is to accept that not everything is obvious to all people, even moderately inteligent ones. It doesn't hurt to keep asking, 'does this still make sense to many people?' rather than saying 'this just the way it is. read the man page and deal with it'.
Linux does have flags like immutable. I'm running Ext3 and you should always use chattr +i journal.dat to make the journal immutable. Other attributes are on enabled via various patches -- including a nice compression flag for NTFS-like on-the-fly compression.
Secondly, some people prefer System V init. I do. It is a matter of choice whether or not it is confusing. Again, I like it so this may be the only section where the author was biased.
Other than that, I agree that Ext2 has some issues. Ext3 addresses most, including some more recent LFS (large file size) patches that give you >2GB support, including for NFS services. But I'd rather have UFS with softupdates at this juncture.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
First, let's look at the numbers...
The Core team is listed here.
Of them, only Jordan Hubbard and Mike Smith are BSDi employees, both having come over with WC. Jordan of course has been there since FreeBSD's inception and beyond, and Mike was only recently voted into Core by popular vote of the...
Three of them come to mind as BSDi employees, though I can only think of 2 without browsing the entire list: Jim Mock and Bill Swingle. My appologies to the third and anyone that I don't know by name.
That is easily neither "most" nor a "very large number", even if I'm way off. But wait! There's MORE!
The list of Additional Contributers is here. This is anyone (Including yours truly) who over the years has had something committed to FreeBSD in the form of code (src), documentation (doc and www) or ports (ports). There are 1135 documented contributers. That's a total of 1357 people who provide you with FreeBSD. (Contributers come and go, and there are also those who may not be listed, but it's a pretty good number, and is probably much higher.)
Second, let's look at your FUD (For it is surely Fear, Uncertainty and Doubt that you are expressing)...
Walnut Creeks' position wrt FreeBSD was always clear. They distributed CDs and marketed it and provided some commercial support. There are plenty of Linux companys that do the same for Linux, yet no one cries foul there (except maybe the same breed of conspirators you come from.)
Jordan Hubbard founded FreeBSD, Inc. to handle the interests of the Project, and this responsibility is being passed to the new FreeBSD Foundation thanks to Justin Gibbs (former Core team member and current committer.) The FreeBSD trademark will transfer to the Foundation. It was held by Walnut Creek previously, but not because they "owned" it but instead to protect the name in cooperation with FreeBSD, Inc. The Foundation is totally not related to either the Core team or BSDi. Justin and his cohorts are seeking legal non-profit status.
When BSDI merged with Walnut Creek, it was clear to anyone with insight or anyone who read the Press Releases that it was only WC they were merging with. You can't merge with an operating system. FreeBSD is wholly seperate from BSDi. The only thing being merged with FreeBSD is code from BSD/OS. Where do you think SMPng is coming from? It amazes me that people still get this wrong.
Sure, there may be code in BSD/OS that's not in FreeBSD, but it was there to begin with. Also any code that BSDi has under NDAs with vendors won't be added to FreeBSD. FreeBSD gets whatever FreeBSD puts into it, end of story. If ANY company, including BSDi wants to take some or all of it and sell a closed source version, more power to them. FreeBSD will continue. It is the BSD License that makes, and keeps, FreeBSD free.
FreeBSD is only BSDi's "product" insofar as they sell CDs. FreeBSD's democratically elected Core team decides the future of the Project, not BSDi.
So it is anything but "unclear."
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
Well the BSD init stuff is very simpl. Here's a quick overview:
/usr/local/etc/rc.d. Thats where you can place your own startup scripts. And they have start/stop arguments just like any Sys V script. The advantage here is you don't need a K and a S script and its all in one place. They must be .sh files and execute in alphabetical order. It's all very simple when you swithc over your thought process. That's all it really is is thinking like X instead of Y. I prefer the BSD style since it is easier to replicate it across systems and alot quicker for setup in general.
therre are a number of rc.X files taht are config files. rc.conf is the main one and anything you would start from there has a number of options for flags, dirs and other things. man rc.conf shows all its features. Its mostly base system stuff that sits in rc.conf. apache is not base either btw. Mostly things like sendmail, bind, ntpdate things like that are in rc.conf. Also firewall, inetd and alot of system controls can be set here.
Then you have
this space for rent
I apologize.
-bugg
In any 4.4BSD derived operating system, the flags can only be unset by root if the security level is under 1. The end result? You've got a bunch of files that the kernel will not let you modify (or depending on the flag, delete, do anything but append to, etc.) without dropping into single user. That means that even if someone gains root, his job is made difficult unless he has local access: placing trojans over important binaries becomes impossible, as does (more importantly) deleting the logs that logged your entry. See page 263 of Design and Implementation of the 4.4BSD Operating System for more information.
-bugg
As someone who uses both (since I run FreeBSD for my web servers and Linux for my TFC server)..
I like both.. Linux does have better support for new hardware.. I will admit that.
UPS Sucks
I like BSD. It is with out question a very good stable platform. It has a lot of cool stuff like Kerbros built in. Its development is more focused them most Linux distros. I think as a server it is better than linux But I like the choices I get with Linux. I fear that BSDi may be able to become as big of a bully as M$ or Red Hat are now. BSDi is full of very cool and talented people but they are beginning to get more and more suits to run the business side of things. IF and when they begine to dominat the market will I still have the choices I have now? Will they try to lock me into some standard or package for there benefit? I hope not. Many cool companies have become dicks once they became big enough. SUN, APPLE, Microsoft. As long as I can Run Debian GNU/Linux to do what I need, I will not be at there mercy. I very important thing to not forget. There is more than just the quality of the code to worry about there are the strings that may come with them. Right now I do not see a problem with BSDi but I fear that may start to change in the next year or so.
I've been mucking with linux for two years now and have just gotten into FreeBSD. FreeBSD and GNU/Linux were developed under different design considerations (and I'm not talking about licenses here). System V works well and I like it, but the more I read the rc scripts in FreeBSD, the more I learn about it too. For me, it a matter of RTFS (read the F'n scripts) to make it do what I want.
/usr/ports directories.
The more I use linux the more I like it. The more I use FreeBSD the more I like it too. Sooner or later it will become easier to maintain one over the other. When? I don't know. But I have a feeling FreeBSD is leading.
I am not a programmer, just a user. I can barely write my own scripts to start the dnetc client, much less debug one. FreeBSD allows the user much more flexibility, IMO, to install software. The 'make install' is an excellent method of getting the latest software in the
Choosing between GNU/Linux or *BSD is difficult in the long run, but it's still 6:1, 1/2-doz or the other to me.
* I'm biased against Windows and I like it that way.
I've been using linux since pre 1.0.x kernels and only happened to start using linux cause some other folks around had been messing with it and it looked like fun (coming from Irix on SGIs where the machines shipped with juggling balls I was very into having fun with new oses. :).
/etc/rc.d/init.d to/etc/rc.d/rc(n).d in Red Hat. This is a potentially confusing scheme, and you can't customize these scripts unless you properly add the runlevel info at the top of the file.
/etc/rc.d/init.d/httpd start. and i think writing scripts for new daemons is cake Am I missing something or is there an easy way to start and stop any service on a freebsd box (short of doing something like killall -9 sendmail)? Some daemons have more involved startup and shutdowns (like database servers) and its nice to have one spot for everything. Am I missing something? (I know, I know, RTFM) I definately don't think it reflects badly on bsd (it only takes about 5 minutes to tweak things to work the way I'm confortable with on flavor of unix) but it would be cool if there was a better way of doing things and I just missed it.
I only just tried BSD (freebsd and openbsd) a few months ago. I've never had a thing against BSD, I just never thought to try it. I was super impressed. I downloaded a boot disk from the freebsd site and three hours later I had installed a kicking box with gnome, kde, gimp, the works. I was even able to get a usb mouse working. I was blown away by the excellent security (took me a bit to get the hang of swithing security levels to let me start x but that kind of security rocks). I think the weakest part of linux is its lack of kernel level security.
So anyway, so here's my gripe about startup scripts:
Most Linux distributions have their System V startup scripts symbolically linked from an init.d directory to the rc(n).d directories, for example,
Umm confusing? I love the init scripts setup in linux. Maybe i've just gotten used to being able to uniformly start and stop any daemon on my box by typing:
None the less, mucho cudos to the freebsd and openbsd crowd. If I had the time I would convert more of my boxes to bsd. -tem