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.
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.
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'.
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.
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
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