Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

Very Non-Biased FreeBSD Review 38

Posted by AilleCat from the heavy-security-for-all dept.
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.
This discussion has been archived. No new comments can be posted.

Very non-biased FreeBSD Review More

Very non-biased FreeBSD Review

Comments Filter:

  • Re:ext2 not quite as bad as shown here (Score:1)

    by Anonymous Coward
    > 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.

  • Linux nuts and FreeBSD (Score:1)

    by Anonymous Coward
    I just wanted to ask that we start no holy wars. If you love Linux you may like FreeBSD. A lot of linux users think that Linux is great and they need no other OS and then start bashing FreeBSD even though they have never used it. It runs Linux binaries.

    Please don't knock it till you try it and understand it. It would be so wonderful if we could all show a united front against the evil empire and fill it with our "daemons converted to good" world.

  • Non-biased? I don't think so. (Score:1)

    by Anonymous Coward
    There are many areas where *BSD is superior to Linux (and vice versa) but these aren't them.

    Linux *does* have securelevels and immutable etc flags in ext2fs. It *can* use BSD-style init (I think slackware still does that actually). It *can* be configured to provide a serial console. Reading /proc may be a bit more work for the programmer but is IMHO much safer than reading /dev/kmem. And it seems that someone definitely needs to read up on exec(3), popen(3) and system(3).

    The author is basically biased and/or he doesn't know what he's talking about. Much more valid points would be (for example) the SCSI subsystem, NFS, the ports system, or USB support

  • Re:ext2 not quite as bad as shown here (Score:1)

    by Anonymous Coward

    The difference is that, last I checked, in Linux root can unset these flags.

    I'm not sure if that was ever true, but it isn't now. See this article [securityfocus.com]. Basically, Linux has a master capability set. If you remove a capability, like the one to modify these flags, it's gone from the system and only init can change it back. The parallel to the BSD securelevel concept is obvious.

  • Linux has something equivalent to this in LIDS [lids.org]. True, it does involve a kernel patch, but you can set up fine grained ACLs for files and directories. You can set files to be completely immutable (even root is denied) and only allow users/processes to read or append to the file. No, this isn't in any mainstream Linux distribution yet, but there are a few of us looking at making add in packages to get it working.

    I'm looking forward to learning more about the FreeBSD security feature, though. This is the first I've heard about it and I thank everyone for the pointers thus far. This has been a really interesting discussion.

  • 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.
  • 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)

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

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

  • Re:It's VERY biased! (Score:3)

    by edhall ( 10025 ) <slashdot@weirdnoise.com> on Saturday December 16, 2000 @09:53PM (#555377) Homepage

    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.

    -Ed
  • The author mentions extra security features of FreeBSD's UFS, such as the immutable flag. 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.
  • >> 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.

  • Re:ext2 not quite as bad as shown here (Score:4)

    by BusterB ( 10791 ) on Saturday December 16, 2000 @03:37PM (#555380)
    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'.
  • Did you mean to say "spending too much time rooting for Linux", or "spending too much time ROOTING LINUX"?

  • 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

  • BSDi's only relationship to FreeBSD is as it's commercial benefactor (ie, they hire some developers and sell CDs and stuff.) Specifically, it's the Open Source Division, which is basically the staff from what used to be Walnut Creek.

    FreeBSD is in the hands of the core team, *NOT* BSDi.
  • I am not wrong, I even pointed this out. They pay people to develop for FreeBSD. Whatever goes
    into FreeBSD stays there.

    We "get" FreeBSD not because of BSDi's generosity and good graces but because of all the volounteers that make up the project. I'm not making light of their (including WC) contributions, I'm just saying it would go on without them.

    Your paranoia is unwarranted and only serves as FUD.

  • I would agree with you 100%....if this review was actually on Slashdot. Did you even read the
    article?

    You're thinking of the biased comments.
  • That's just it... chmod isn't the relevant place.

    [man -k|apropos] flags

    chflags(1) - change file flags

    As for the absense of See Also's on Linux man pages..well...documentation on Linux isn't as great as everyone would like to believe.

  • The Free in BSD(Was:It is more than just the code) (Score:3)

    by Lazaru5 ( 28995 ) on Sunday December 17, 2000 @10:07AM (#555387)
    Note: "FreeBSD Developer" is defined as anyone with CVS commit privileges.

    First, let's look at the numbers...

    The Core team is listed here. [freebsd.org]

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

    ...Developers list is listed here. [freebsd.org] Though this [freebsd.org] is the authoritative list. The handbook page lists 232 total developers.

    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. [freebsd.org] 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."

  • Erm, actually it's chattr in Linux. You seem to not understand the difference between file flags/attributes and the chmod security mechanism.
  • Most of the BSD developers are not on BSDi's payroll, some of the more prominent and core team may be. FreeBSD is owned by the FreeBSD Project, period. The BSDL which is what FreeBSD isunder means it is free, period. FreeBSD is not going away or going to be taken over by the big evil corporate boogeyman.

    It is FUD to say that FreeBSD is being taken over by the Microsoft like comapny called BSDi. They are pushing FreeBSD yes thats because they sell support for it. Thats how they make money. And you can still download the iso or ftp install for free or buy the damn cd's.
  • Well the BSD init stuff is very simpl. Here's a quick overview:

    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 /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.
  • You're correct; my previous statement is withdrawn.

    I apologize.

  • Re:ext2 not quite as bad as shown here (Score:3)

    by bugg ( 65930 ) on Saturday December 16, 2000 @08:38AM (#555392) Homepage
    The difference is that, last I checked, in Linux root can unset these flags.

    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.

  • I liked the review, pointed out a few topics most reviews don't mention, however there are some flaws.

    immutable flag - man chattr

    init scripts, if you really prefer them, install BSD init.
    I like how my debian scripts are setup
    nfs stuff in one file, bind stuff in another file nicely segmented and easy to see what is going on

    logging read up on the utilities out there, I've been using ippl for a while, does an excellent job.

    Besides those few gripes it was a nice coherent review, likely much nicer then this comment.
  • I hate to admit it but Linux does edge out FreeBSD in supported hardware. It'll support the $5 tape drive you got at a college auction. Why should someone spend time developing a driver for a tape drive deemed worthy to hold $5 worth of information?

    But I will agree with you on superior BSD support for SCSI, USB, etc. Linux RAID? Linux should worry about good SCSI first.

  • Linux *does* have securelevels and immutable etc flags in ext2fs. It *can* use BSD-style init (I think slackware still does that actually).

    You seem to be forgetting that Linux is just a kernel. The distributions are mostly independent of this. Kernel/Userland aren't exactly tightly unified in Linux. Thus, it's not Linux that can use BSD style init, rather the distro. Yes Slackware does it and iirc so does Stampede but they're transitioning over to SVR4ish.

    It *can* be configured to provide a serial console.

    Your point being? Just about anything can be? If your ass had a chip I bet I could make a console out of a colestomy bag.

    Reading /proc may be a bit more work for the programmer but is IMHO much safer than reading /dev/kmem.

    Linux /proc is kinda silly to begin with. cpuinfo is one example. /proc safety? There's an advisory every other week on BUGTRAQ for /proc. Being able to make a couple syscalls is A LOT faster than having to drag all that nappy VFS code into things.

    The author is basically biased and/or he doesn't know what he's talking about.

    The author did make some valid points, he wasn't trying to speak over the head of 90% of the readers out there. Just because you don't like it doesn't mean its false.

    Much more valid points would be (for example) the SCSI subsystem, NFS, the ports system, or USB support.

    Hell, Linux just got NFSv3 and it's v2 implementation is kinda shitty. Just go look back at the inominate benchmarking from a few months ago. Linux only now has experimental USB, other's have had it working for years! Linux RAID? Linux should worry about good SCSI first.

  • Linux has its place and so does FreeBSD..

    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.

  • Reading /proc may be a bit more work for the programmer but is IMHO much safer than reading /dev/kmem.

    This is true. However, even better is to have a good API to access to access kernel data. sysctl is unfortunately not widely advertised enough, which means that SNMP daemons like UCD-SNMP have not been fully converted over yet. The sysctl interface offers the well-definedness of /proc with the speed of kmem grovelling (and like /proc, it doesn't require privileges for read access unless you are trying to read privileged data).

    Reading /proc is easier for scripts, but I hate having to redo all the structs that are already defined in system headers and writing code to fill them in. And for some reason (I've never quite figured out why), /proc seems more prone to write kernel code for.

    My main dislike for /proc stems from a philosophical standpoint, which is that the kernel has no business with providing a user friendly interface -- that's what userland is for, but I'll happily sidestep such philosphical issues if they are shown to be overshadowed by other advantages.

    For completenesses sake, the main advantage of kmem grovelling is that it also works on kernel coredumps. To me, it still leaves me in awe to run netstat or ps on a kernel coredump and be able to tell exactly what was going on at the time of the crash.

  • These flags are affected by the chflags command.

  • Thanks for that, I have been using FreeBSD for over a year and I haven't seen an explanation that good yet. I never got the hang of startup scripts, I have been manually turning some services on when I have to reboot.

    If I had to reboot more often I would have taken the time to figure this out earlier. ;)
  • What does Pay to develop mean? As I understand it by talking to BSDi employees not all but most if not a very large number of the Free BSD development team are BSDi employees. This may be wrong but If it is not there is the possibility of the Free BSD name and product's control itself being no more than the free version with less features than the core BSDi version. This is a very unclear relationship is Free BSD really Free of BSDi control or is it really there product. If not now how about in the next few years. Who owns the trade mark "Free BSD" I think it is OK ether way as long as it is clear so people will not be fooled in to thinking it is as free as Linux is now when it might not be. It is not "FUD" to wonder about such things and I for one would like some more Official clarification of who and what owns and controls Free BSD and what exactly is there relation ship with BSDi and the rest of the world.
  • 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.
  • There is a big revamp of the rc scripts in the works for the FreeBSD 5.x-current.
  • 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.

    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 /usr/ports directories.

    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.

  • BSD is Cool but Confusing startup scripts? (Score:3)

    by nadachicken ( 218431 ) on Saturday December 16, 2000 @12:53PM (#555404)
    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. :).

    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, /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.

    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: /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.

    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
  • Taken from the article:
    "OpenBSD's team reviews all code, looking for possible exploits as well as any other userland exploits."

    This is simply not true. The OpenBSD doesn't look for 'possible exploits', they just fix bugs/buffer overflows. It just so happens that sometimes these bugs result in exploits. I believe it was Aaron Campbell who said that he doesn't know the first thing about writing exploits, he just fixes code that is 'wrong', and in my opinion, this is how it should be done.
  • Your point being? Just about anything can be? If your ass had a chip I bet I could make a console out of a colestomy bag.
    ------
    I think this would make for a crappy console.
  • linux vs freebsd.... rather linux vs freebsd vs windows vs beos, its all about choice and what os gives u the most features you require and want. i went from win2k to freebsd for server/dameon needs but on my personal play/dev/work box im stuck on freebsd wondering if i should just say phuck it and build my own damn os. NOT; hear me, _not_ 1 os i have tried gives me total satisfaction. i want the best of all rolled into 1 os. after reading 8 million reviews of personal opinions and maybe 2 of fact i am no closer to deciding. might as well pack it up and move to the rain forrest with some sun block, a hunting knife, sheep skin condoms, and some kidnapped girl.

Slashdot Top Deals

This file will self-destruct in five minutes.

Close