Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

I'm surprised no one has mentioned the problem I had getting the NIC to work on my 10BaseT network.

I was hoping someone would be able to explain why I needed to set it to 10baseT in the installation and 10Base2 after installation. Is this something I should report as a bug or am I just clueless here?:)

having installed it several times now, its always been good in the install. never failed to detect and use both nics (every machine i installed on had two nics, including a notebook with a pair of pcmcia ones) never had to do anything beyond just letting the default media type do its thing.

ftp is great, when your network is configured, it goes out on the net and gets a list of ftp sites for you. (unless you tell it not to) i dont know of any linux dist that does this. IMO, getting the CD is really more for supporting the cause than actually installing the OS. if you split up the architectures, all the install packages for a given one fit on a (100meg) zip disk. (about 70megs for x86)

The Daemon has been the emblem of BSD for a long time. The one you associate with FreeBSD appeared long ago on the "Design and Implementation of 4.3 BSD" cover. He is copyrighted by Marshal Kirk McKusick. Please have a look at Kirk McKusick's site [mckusick.com] if you are still confused. How you came to your assumptions is beyond me.

Funny. I've been hacking around with an OpenBSD box for the past few days, and now two stories about it appear on Linux Today.

Anyway, my install experience was slightly different from the one recounted here. Yes, the disk partitioning tool is horrid, but it's not much different from early Linux fdisk. I had to start over a couple times until I got it right, but I could do it again easily now. The documentation was well written and helpful, too, something that I have found is the general case with OBSD.

Once past that stage, and a problem I had with a bad hard drive, things went very smoothly. I had made an iso image myself, but I forgot to add the -r flag to cdrecord, so the file names got truncated. I ended up simply copying the CD to my Linux desktop box and serving the images back to the install, but it still worked fine. No extra reboots, just some time and a nicely set up system.

Interestingly, the thing that most impressed me, aside from the thorogh documentation, is that which the author had bad trouble with: network setup. I had a cheap ne2k ISA plug-and-pray clone in this box which is hell to get working with Linux. OpenBSD detected, configured, and activated it automagically, and the configuration persisted, and worked as soon as I booted my new system.

And, did I mention, the documentation is very nice?

I more or less agree with the summary here: I wouldn't recommend it for a desktop, but for a server system, so far, I would give a very strong recommendation.

When you're talking about Unix, the line tends to be blurred a lot. My machine for example does it all, server tasks, workstation tasks, everything I need it to do...and it can, it's Linux

But I think one of the main reasons people advocate Linux for workstations is its wide support of hardware and quick support of hardware. I would switch to FreeBSD in a second if only I could use my IDE cdburner...but I can't, so its Linux for me. Just one example that illustrates the bigger point.

Another reason for this (IMHO) is that you will get super-deluxe security w/ OpenBSD, You can run NetBSD on more platforms, and FreeBSD has the highest level of stability (on i386). I think these characteristics are much less important for workstations, where periodic reboots are ok, everything runs on intel chips, and no server processes are running.

When it comes down to it, you just have to know what you need, and what each OS can provide. The server/workstation "rule" is more of a rule of thumb, just a guideline.

Unfortunatly, my experience with trying to get help in #freebsd has been pretty bad in general, and I'd like to think I'm not asking very dumb questions. Generally, it's a bad place to go for help; in fact, I'd say it's the wrong place to go for help since the topic is often "This isn't a help channel! http://freebsd.org or RTFM".

There is #freebsdhelp, which is much more 'user friendly' but unfortunately doesn't have as many people in it (when someone in #freebsd does decide to answer your question you usually know immediately, whereas #freebsdhelp is much 'slower').

I really love FreeBSD, and I *personally* find it much easier to work with than RedHat (the only Linux I've ever tried). I just wish the online support was a little better.

One of the first things you have to overcome when installing a unix system for the first time is the belief that your former system rather it be dos or windows was somehow better. There is an established standard (FSSTND) that dictates where files should be placed but more importantly dictates where files can be found which is critical for any system administrator; Instead of wading through "/programs" you can be reasonably assured that if it's a userlevel binary it's somewhere in/usr/bin or/usr/local/bin (there are exceptions to the rule where categories are made such as/usr/X11R6/.) This also makes it much easier to migrate from different versions of unix since the structure is generally the same.

what's the difference between/usr and/usr/local and why can't i just link/usr/local to/usr?

Well technically there's nothing wrong with that, (/usr/local/ is meant for if you have a nfs/usr you can mount a/usr/local with binaries relevent to only the local machine). I find however that it serves a more useful purpose in separating out the files that came with my distribution/or the files i installed as packages from the files i've compiled on the system. If i ever have to clean up my system all i have to do is wade through abit of/usr/local.

So in answer to your post there is a predictable placement to where the files are located it jsut takes abit of getting used to.

I thought this was a pretty fair review - I had a similar experience installing OpenBSD, though most of my install hassles were related to getting X working.

As a mainly Linux user who's used Unix a lot in the past, I found OpenBSD very interesting, and I am planning to use it as the basis for a firewall, where its relatively small ports collection is a feature not a problem. My theory is that script kiddies & others will be less likely to have exploits for OpenBSD, due to its smaller user base and more stringent auditing.

This has already been done to some extent - Definite Linux is a Red Hat 6 derivative that includes crypto, while there are a number of secure Linux distro initiatives that will eventually come out with more robust and secure versions of Linux. There is also at least one security auditing project for Linux.

However, unless someone takes a snapshot of Linux and then spends a long time auditing it, I can't see that Linux will end up as well audited as OpenBSD.

it's an ongoing series. there was an article last week, where he just gave a basic overview of what he was planning on doing. there should be an article next week giving his overview on freebsd, and then one following that comparing the two bsd's and linux.

besides, he's only had it installed for a week...i've had linux installed for close to a year now, and don't know all the in's and out's. sheesh...

The Cheapbytes CD comes with a very clear, step by step guide regarding a sample install of OpenBSD. Also, their "FAQ" ( which is more like a small user's manual ) is excellent. However, I agree that the disklabel is cryptic.

OpenBSD is an excellent choice as a solid server OS for low end hardware. However, compared to FreeBSD, it's not really ready for the desktop yet ( FreeBSD has a much larger ports and packages collection. Also, OpenBSD's filesystem, while rock solid is also sloooowwwww ). The nice thing about OpenBSD is you can fire it up and forget about it. You don't need to worry about the "patch of the week" like you do with linux.

I think it's high time that the linux distributors started shipping crypto, even if that means shipping from Canada ( as OpenBSD does ). It would also be nice to see some more sensible default settings on the linux distributions.

Cheapbytes give you the option of donating. One of the things I like aboutr Cheapbytes is that they seem genuinely concerned about free software. The reason I purchased from there is because I visit the site a lot. I'll probably get OpenBSD 2.6 from openbsd.org though.

Security, reliability, availability of server apps, an OOTB config that is secure, reliable and has the right server apps. Performance is sometimes important, but sometimes ( ie a small server ) it's close to irrelevant.

What features are desirable in a "workstation"?

Desktop applications, desktop applications, and desktop applications. Performance. Of course, security, stability and reliability are still important, but not as critical. The machine is quite possibly behind a firewall which makes security less critical. The machine is not running critical services which makes reliability less critical. Stability is less important than supporting the latest hardware.

Does optimizing for one of these environments pessimize-- or at least compromise--the other situation?

yes, sometimes it can. For example, OpenBSD's default file system is IMO unacceptably slow for a workstation. However, on a critical server, it's reliability could be an advantage. On a workstation, I'd rather use a filesystem with write caching. Another example: if the developers pay more attention to putting in as much software as possible into a distribution, rather than fixing the software that they already have, the result is a nice desktop system that is possibly full of security holes.

Of course, a workstation OS can benefit from enhanced security and reliability all other things being equal. However, in practice, there is often some kind of tradeoff.

Just as you want a solid, sane, robust system for a computer that provides services for an entire department, so too do you wish the same coherence and correctness on my very own computer that you are the principle user of.

All the "correctness" in the world will not help if you can't run the applications that you need to use. For example, OpenBSD's "correctness" isn't much help to java developers.

Certainly, at this point, OpenBSD suffers as a workstation OS for two simple reasons: the fact that the availability of apps is small ( the ports collection is tiny compared to FreeBSD ) and the hardware support is relatively small. On the other hand, while linux leads the way in terms of apps, it lacks OpenBSD's security features.

OpenBSD is licensed under the BSD license, so porting features to Linux (GPL) without raising licensing issues can be tricky.

Not true. It is the other way around. There is nothing stopping you releasing BSD code under the GPL ( AFAIK ). The GPL is the more restrictive license, and it is bringing GPL'd software into a BSD that proves difficult.

The main difficulty with adding OpenBSD's features to linux is that most distributors have their hands tied by export regulations. So all of OpenBSDs built in cryptography cannot be built in to any distribution that is developed in the USA.

I use it in the simplest sense: to mean an application that a desktop user would use. This includes anything from Pine to Word Perfect to LaTeX. Linux has the advantage that the applications that come with it are all very much up to date. It also has some applications that are unavailable on OpenBSD. Whether or not this is an issue depends on which applications you need/want to use.

As far as desktop environments are concerned, I prefer KDE ( or more to the point, my users do ). Fortunately, there are OpenBSD binaries for KDE now.

The ports collection is definitely better on FreeBSD, though I don't know what the exact number is. I'll fess up and admit that OpenBSD is the only BSD I have root access to.

It seems to me that it's more important for a machine that has many users to be fast

That depends on the number of concurrent users, as well as what those users are doing. If they are all compiling and running emacs, you have a point. However, if the machine is a webserver getting 10000 hits a day or less, then it doesn't need to be very fast. Moreover, there are several applications for which OpenBSD's file system will perform just fine.

As for file system speed, what do you mean?

I guess I can only compare OpenBSD to linux. OpenBSD doesn't cache directory writes, which makes it very slow for recursive operations that require directory writes ( tar xvzf , cp -a , rm -rf ) Unfortunately, I can't do a fair benchmark now because my OpenBSD box ( which used to run linux ) is a Pentium 133 and my linux box is a Pentium II. But I'd suggest you should be able to verify this. I urge you to try benchmarking any or all of tar xvzf, cp -a and rm -rf on a directory containing several files ( thousands ). I bet you a nickel that ext2 wins (-;

I guess thourough depends on the reader. Personally I didn't think it was thourough either, but someone who has never used OpenBSD before may have felt it was a great resource. There are not a lot of web resources available for OpenBSD, something I hope to change.

I try to keep an ongoing on-line diary of my experiences installing and using and experimenting with OpenBSD. It available here [deadly.org]. Four years ago, you would have been hard pressed to find mention of Linux anywhere, much less a thorough review. Now OpenBSD is getting some attention.

Personally I think Matt should be credited with at least being curious enough about OpenBSD to give it a try , and willing to share it with the community. That's what it's all about right?

I'm not suggesting that Linux adopt OpenBSD's development model. I'm suggesting that Linux pick up some of the attitude. Namely, a driving belief in correctness, and an attention to details that might impact security.

You can ignore these sorts of issues only at your peril--if you take security for granted, and assume it will all come out in the wash, you'll find a few things in your wash that aren't pleasant.

Then again perhaps Linux is moving toward being a desktop OS. The emphasis lately seems to have been on support for any and all hardware, plus easier configuration, plus more support for userland applications.

Perhaps Linux is destined to be the desktop Unix, whereas the *BSDs will wind up being servers.

In the short term that's unlikely to be the way it goes--Linux will make more and more inroads into servers. But in the end, you either deal with security in a comprehensive and systematic way, or you get out of the server business.

Linux should take a long hard look at OpenBSD and learn. The OpenBSD people have done a fantastic job of dealing with security, and have settled a lot of important issues through hard work and careful thought.

Going forward, it's going to be important for Linux to adopt many of these ideas, but especially this kind of attitude.

Interesting point. As the poster, the text you're seeing in the story is pretty much what was submitted. I've got a choice of either using that text as is, and keeping the submitters words, or changing it completely. and starting with something like "Nicedream sent in this link to..." instead. Wherever possible I try and retain the submitter's text, since that's the core of Slashdot after all.

What I don't want to do is start reviewing or commenting on the links in the summary -- some of the stuff that gets posted will have that, but it will be from the "Read more" link if at all. In fact, there's a good example of that coming up in about 4 hours time.

No suitable URL's unfortunately but reading the mailing list archives may help. There you can note that the folks at OpenBSD have been through fixing all of our favorite YAREs (YetAnotherRootExploit) and have gone into details like file descriptor leaks (ever head of those;-). And so on.

And I love their attitude (to Paul Vixie software especially). Running named chrooted and as a non-root user;-). And there are many other small peeks and pokes here and there that make it much more bulletproof even at factory defaults compared to RedHat for example.

That is besides support for every sensible auth method/technique under the sun (one time passwords, encryption everywhere, cypherchained blowfish for storing passwords, etc).

So why the heck doesn't he write the same thing and shut up about it? A quick perl or even shell script involving find, diff, sum (md5sum) should easily suffice and could probably be knocked up in under 5 minutes flat.

And the result will be that it will have at least one symlink exploit, will crash the box on some directory structures or do something else as dumb as it gets.

Writing scripts like that is not a 5 min job (unless you want to provide a nice root-comporomise backdoor).

Because the XDM way of logging into systems is in a fundamental violation of the Unix way of initializing your environment, and it shows. XDM discards the entire concept of your login shell, and with it the entire concept that you can initialize your environment once and use it thereafter. (You should see the hacks that some vendors, like SGI, use to try to weasel their way around this failing (for SGI, scope out the userenv manpage sometime).)

You can kludge around this. But all the approaches are kludges, with all that implies: they are not general, and they are not necessarily supported in the latest fancy magic thing to come along. And you will go to extra work if you want to have things work seamlessly on non-XDM logins too. There is nothing with the simple and straightforward elegance of the login shell concept.

This review was anything but thourough! How does the uninformed user decide to use this rather than Linux. There's a lot of hype about OpenBSD being hypersecure by default. But what does this mean? How does this apply to some yahoo who wants to build a webserver or a firewall?

I like OpenBSD, I like Linux, I like Macs, I use what ever is best for job.

I wish these people would start to do objective comparisons of the feature sets of each OS.

I'm just pointing out a trend I've noticed on a lot of these "tech" sites. No depth.

It's great that any monkey with a net connection can install Linux or *BSD, but no one seems to be talking about how to use the system once it is installed. No one talks about the strengths or weaknesses of their chosen *nix.

It's all just "Linux only take 15 minutes to install!!" Bullshit, there's more to installing software than swapping disks and clicking on the right buttons.

This is not meant to be Flamebait [hence I've not posted anonymously], but a serious question.

With the rapid advance of Linux over the last year or two, are the *BSDs "fading" into the background ? My impression is that even the niche markets which the various BSDs are directed (security/ network...) appear to be about to be taken over by Linux.

I too felt this article was a bit shallow - OpenBSD requires a longer more in-depth look. I get the feeling that OpenBSD is not naturally a newbies first choice, although a smooth installation process would obviously be a major plus.

What I would like to see is an article by some SysAdmin on his long term experiences with it and whether it is a good secure system.

I recently installed OpenBSD on my home machine, and after spending about three weeks trying to get various things to work, I decided I'd be better off with Linux.

Before I began, I made a list of programs/functionality that I needed, both for the server tasks (FTP, Telnet, WWW, SSH, IP Masquerading, etc.) and as a workstation (running WordPerfect, Netscape, playing MP3s, etc). And as I got things to work, I crossed them off my list.

The good news was that a lot of things worked right out of the box (or straight from the ports tree). Getting bash, trn, X, ssh, NAT, and basic networking was a piece of cake. Unlike the experience of the author of the article, the install handled my NIC and cable-modem-dhcp setup automatically (unlike Linux where I had to use a non-standard dhcp program and another program to "login" to my Road Runner accoutn).

But after the initial install and setup, there were several things that didn't work for me, and I didn't really get them working satisfactorily:

Printing. I've got a HP Laserjet, and the basic printing works fine. Ghostscript rips PS to PCL just fine under Linux and OpenBSD. But under Linux, RedHat comes with an, IMHO, awesome magic filter. Just type 'lpr foo' and it'll figure out what foo is and Do The Right Thing. I spent a lot of time trying to write a magic filter for OpenBSD, and never really got it to work as well (mostly because some of the image and text-processors either wouldn't work, or because file gives the wrong answer for some image types).

Linux emulation. Everybody seems to say that the Linux emul under OpenBSD is the eighth wonder of the world, but my mileage definitely varied. I can't say that I really got acceptable results for anything, much less everything. And this is a show-stopper for me. If I can't run Linux binaries (and as long as there are basically no OpenBSD binaries), OpenBSD is not an option for me. I need some kind of word processor like Star Office or WordPerfect, for example.

Sound. I never got sound working, and I couldn't find a damn thing about it on the net.

Compiling. After a few futile attempts, I learned that the ports tree is the way to go. But if there isn't a port of something (say Apache with PHP and mod_perl), it's a pain in the neck to try to get it to build. Maybe it's me (in fact, I'm sure it's me), and maybe other people can get it to build just fine, but it's beyond my skills. With Linux, someone else has already done everything I've ever thought of and put up a step-by-step website. So if I run into trouble, I'm ususally just a google-search away from getting it done.

One thing I'll say though, it gives me a newfound appreciation for the smooth Linux installs. It took me a few times though to get the OpenBSD install to take. Mostly because the whole disklabel thing was new to me, and I figured out that the a slice was root, and that the c slice was the whole disk. But I didn't get that the b slice was swap, so my/usr didn't work until I figured that out.

Also, it reminded me that Linux on the desktop does work, if you've got a certain ammount of technical knowledge. My Netscape doesn't crash. I can play MP3's and use a word processor and spreadsheet (Gnumeric). The network configuration and IP masquerading isn't as cool as OpenBSD's, but it does work.

I think you forgot a few things unless you include them under the topics above.

Libraries - possibly under binaries?

Headers - under source?

Data - OK this sounds silly but while we're at it why don't we specify places for data to go and not to go.

I also think your config files need (in many cases) two 'versions'. The system standard and a user's. So you may need config files in a user's directories too. I do like this idea of seperating things into places that are clear what goes where. You probably could go and build a linux distro that has this (although it'd probably be a pain). I'd also agree that I like the version of things in/bin/conf/src etc, but a problem here is what do you do with possible conflicts? What if 2 programs use a config file with the same name? Really this is a problem I can forsee with this. And further this entire setup should be mirrored in any user's directories, just to keep things neat. -cpd

Printing. I've got a HP Laserjet, and the basic printing works fine. Ghostscript rips PS to PCL just fine under Linux and OpenBSD. But under Linux, RedHat comes with an, IMHO, awesome magic filter. Just type 'lpr foo' and it'll figure out what foo is and Do The Right Thing. I spent a lot of time trying to write a magic filter for OpenBSD, and never really got it to work as well (mostly because some of the image and text-processors either wouldn't work, or because file gives the wrong answer for some image types).

RedHat printtool and print filters are nice, but they are not the _ONLY_ such software out there. magic filter is mmore powerful and flexible and certainly is available in OpenBSD ports.

Linux emulation. Everybody seems to say that the Linux emul under OpenBSD is the eighth wonder of the world, but my mileage definitely varied.

Actually I have never heard people paising Linux emulation in OpenBSD, I have necer used it myself. However, the FreeBSD linux emulation is very decent.

In terms of modern hardware, Linux supports at _least_ as much as openbsd if not more. UltraSparcs and SGI Indy are examples of Linux, and not-*BSD, supported platforms. However if you got something _very_ old, like SUN 3 or VAX or old decstation (they are so slow that they all belong in a garbage collector imho) then you can run NetBSD on them...

I've been running OpenBSD since the 2.1 release. I started out with it because it was the only thing I could get on an old MacIIci, NetBSD notwithstanding. All the nifty bells and whistles rolled into the *nux distros I've used are pretty nice, however, for a clean, well-laid out file system, with no extra cruft, one can't beat OpenBSD. Yes the ports thing is pretty nice too.

Now have two intranet webservers running OBSD i386, one running OBSD Mac68k, one running OBSD Alpha, all in a WinNT shop...using Samba to allow users "drag-and-drop through NT Explorer" for their webpages.

OBSD is still running my firewall at home for the DSL connection, and I've got it on my IBM 560e.

It rocks!!! Please buy the CDs and contribute to the cause, the stickers that come with the discs are well worth it.

I'm not "busting" on anyone. If you want OpenBSD to survive, and thrive as the wonderful thing that it is, you need to support it. OpenBSD's support comes almost entirely from CD and T shirt sales. Feel free to download whatever you want, all I'm suggesting is that if you like it, support it. Besides, you can't download the cool stickers!

What. the sort of attitude that finds a broken box to install OpenBSD on, complains when things go wrong and doesn't know about a) Debian's package management b) the 'cruft' utility on the Linux scene?

D'oh.

And as for this: I simply LOVE the way that OpenBSD sends root a daily listing of all the file permissions changed and actual diffs of the configuration files in/etc.... One way or another I need to have this functionality on my Linux servers.

So why the heck doesn't he write the same thing and shut up about it? A quick perl or even shell script involving find, diff, sum (md5sum) should easily suffice and could probably be knocked up in under 5 minutes flat.

It is *not* "Linux's fault" that no distro either he or I know about do this as standard (and his review would be wrong in giving this impression): it's also not something that should come "with linux" so that as you open the box, the whole sodding lego falls out just the way you want it to work; it's something that needs implementing and filing away under an appropriate section of Freshmeat [freshmeat.net]. And then you educate the folks who'll be using - nae, administering!- these boxes to USE freshmeat properly!

Congratulations then on picking the right hardware the first time. I got two LinkSys LNE100TXs naively thinking that since they were on the supported hardware list, they would work. As it happens, 2.5 incorrectly matches their chipset (PNIC-II) and tries the wrong driver. I dropped a 2.6 kernel in and all is well, so the fix didn't take a lot of work or a big download, but without the wise guidance of the misc@openbsd.org mailing list I'd have been in deep bandini. To sum up:

+ If you have the right hardware, the install is likely to be smooth.

+ If you have the wrong hardware, WOE BE UNTO YOU! Your only recourse will be to throw it away and get the right hardware.

+ Study of the mailing list archives is mandatory. Among other things, it's the only way you'll ever know which is the right hardware and which is the wrong hardware.

Far from being a bunch of obnoxious RTFM'ers, the OpenBSD crowd are by and large very helpful. I felt honoured that Theo De Raadt himself responded to one of my posts.

I dunno, I'm on misc@openbsd.org and I'd say that both "helpful" and "obnoxious" are well-represented. Every week I see people being helpful without being obnoxious, obnoxious without being helpful, and helpful and obnoxious in the same message. This may come from the top -- Theo is arguably the most helpful and the most obnoxious of the lot. Then again, that also describes the traditional composition of nearly all of Usenet, so you be the judge.

A NAT/Firewall distro, something with reasonably easy installation that would put and install all the neat packages to make a routeur/firewall for cable/adsl owners. OpenBSD seems ready to do it but the installation doesn't look pretty.

I can understand why you ask this, given all the news/hype over Linux lately. But just because there isn't a relative proportion of news/hype over *BSDs, this doesn't mean that the software is any less valuable.

I am using OpenBSD for security solutions for my clients and I am very impressed and satisfied with it. Also, because it is less crufty than a similar Linux configuration, it is ideal for dedicated Internet devices. The next decade will see an explosion of these.

You know, there's a reason why binaries are spread out so much on your distribution./bin and/sbin are for *required* binaries, stuff that *has* to be there during bootup, like fsck and sh./usr/bin and/usr/sbin are for optional binaries, while/usr/local/bin and/usr/local/sbin are for local, machine-specific programs (and, sometimes, for non-packaged binaries). You might find a/opt, too, but that's somewhat nonstandard. I first saw that on a SPARCstation at college a number of years ago - mostly, they dumped optional software, like bash and other GNU utils, in there.

Why do you need all those directories? Try mounting / as read-write and/usr read-only some time. It might save your system.

I hate doing things the same way that they've always been done as much as the next guy, but there are, in general, reasons why we do things in a certain way when it comes to the long history of UNIX. Chances are, it's one of the better ways of doing it. You need to research the reasons why things are done this way before you start questioning it. After you understand the reasoning, that's when you should question it.

I'm not saying that it's a bad idea to move everything into one directory (actually, I think that's a horrid idea); rather, I ask that you research the reason why things are the way they are on your Linux system before your propose change. You might find out that you like the current way of doing things better once you understand it.

I don't understand why all these comments saying "hey, it wasn't that bad for a newbie's overview!" are getting moderated up. I mean, once was good enough. We get the point. The moderators want us to say it was a good article.

Personally, I thought it was about as interesting as a 5th grade book report.

"This was a difficult to read book. It was a good book, though. I had to actually read the first chapter before I could wade into the book. The list of contents was very good. Everyone told me this was a good book, and I agree that it is a good book, because it was very interesting. After I got past the first chapter, I realized the chapters were pretty minimalistic and not that hard to figure out after all. The plot was about a hero who had to face a conflict. He beat the conflict at the end. In conclusion, I thought this was a good book."

I don't see the problem with the Linux documentation that so many people seem to be complaining about. Yes, there's a great deal of information out there. But, you managed to find your way to Slashdot, didn't you? There are millions, perhaps billions, of web sites out there, yet you somehow found a web site that answers your questions, reports on news you care about, and hosts essays written by people you admire.

If you can find Slashdot, you can find the proper man page or howto document.

I'm sorry, but if you can't figure out Linux, then you're really not the guy to be writing about OpenBSD.

I expected to see an in-depth article about firewalls, custom-written daemons, how the security relates to the average Linux desktop install, how difficult (or easy) it is to admin the system with all that security in your way, the state of hardware support, how it runs on alternate architectures, etc...

I am one new FreeBSD user. After installing 3.2 I found that the file structure made more sense. Also I really enjoy the freebsd website when searching for an answer it is very well laid out and helpful, and I really like/usr/ports.

I will prob still run some type of Linux from time to time to check up on the progress but for my small cable modem firewall/gateway I will run *.BSD.

That was one of the worse articles I've ever read. They had some guy that seemed pretty clueless and stumbling through an install giving his impression of it. OpenBSD is very simple to install. I hate these people that are laerning Linux and think that's UNIX. It's close but not quite, it just gives you a taste of how things work, though not properly. I'm all for people learning Linux and getting into the UNIX way of things, but they should have some experience under their belt before they start doing reviews on Linux.com, come on! It's a shame it was shown is such a bad light, it really is a great OS.

If you already have hte system installed -- there is probably a bunch of information in/usr/share/doc as well. Now, there isn't as much info on how to get going as linux -- but there is a lot of info for FreeBSD out there (I can't say the same thing for other *BSD's unfortunately). On a side note, 2.2.7 is as BSDish as you can get.----------

Actually, I think it's exactly what they need. My thoughts when installing a system are completely different than a newbies. Even if I hadn't installed that particular OS before, I think my results would be skewed because I've used other unix or unix like systems. Remember, he's writing to a particular audience. That audience is those that read linux.com.----------

I did recompile my FreeBSD kernel on numerous occcasions, but always had that ``did I do it properly'' feeling that I've never encountered with Linux.

I don't see why it's hard. cd/usr/src/sys/$arch/conf cp GENERIC MYKERNEL ee/pico/vi MYKERNEL (possibly open up another term to look at LINT in the same directory) after done;/usr/sbin/config MYKERNEL cd../../compile/MYKERNEL make depend make make install reboot -- in the rare case where your kernel doesn't work, you can just boot kernel.old or kernel.generic and try again. Remember to read error messages when compiling the kernel (just like when compiling linux kernels !)

It's almost exactly the same on all BSD based systems including BSDi. I think it's just inexperience with the type of system. I felt the same way when I first tried linux after using BSD and SunOS for years.

Although some of the 'snobbery may be true, there are still people who are willing to help newbies -- just like linux. However, it IS annoying when a newbie asks a question that is readily available in the documentation/handbook/mailing list archives. Give a man a fish and he'll always come back for more -- but teach a man to fish...

Another thing I partially agree with is the partitioning scheme. Disk druid (or whatever) should be a little more intuitive. I once set up a system and downloaded all my distributions, then configured some menu options, then reboot. To my horror, it said that there was no bootable partition. Unfortunately you can't set up a bootable partition that goes beyond 1024 cylinders (tried making / 27 gigs). I had to totally re-install. Thank god I have a fast internet link and get 690k/s from the MIT mirror:).

Anyway, once the system is installed and you get aquainted with it, it's very nice to use. Some of the things you have to setup are possibly hard -- but I don't think they are much less intuitive than most linux distros. I think it's that you just have to get used to it. I myself experienced problems using slackware, then redhat (from which I had to sit there deleting crap I didnt want for 20 minutes and re-arrange the crappy rc files).----------

Steeper learning curve? I doubt it, unless the you're comparing redhat to them. Debian and slack can be equally daunting to a user. Of course, anyone reading Linux.com is probably using redhat anyway...----------

One model I've seen used, which I quite like, is to have binaries install into it's own tree, off/usr/local. eg:/usr/local/egcs,/usr/local/ghostscript, etc. Then use the/bin,/usr/bin and/usr/local/bin purely for symlinks.

This has the advantage that it's quick and easy to do upgrades, or install new packages, with no nasty side-effects if there are name-clashes, and a guarantee that if there -are- multiple versions, you know exactly where they are.

It also has the disadvantage that it becomes VERY difficult to see what's installed, after a while. The filenames get horribly long, and the directory becomes impossibly cluttered. It also makes it more complex to do audits of what's changed, as you can't just go into the/usr/bin directory and look. You have to go through a multitude of directories to get that information.

IMHO, there is no "perfect" scheme. Everything is a trade-off. The more you split the binaries up, the easier maintenance becomes (especially automatic maintenance), and the easier it is to list what packages you have, even if you don't have a package manager.

OTOH, splitting everything into/,/usr,/usr/X11 and/usr/local keeps the heirarchy uncluttered at the expense of the directories themselves. It's harder to see which program comes from which version of which package, but you -can- be sure where the master copy of a given file is.

According to the X11-toolkits page [freebsd.org] in the FreeBSD ports collection, the current version in the collection is 1.2.6. and, according to the GTK web site and the GTK mirror FTP site I tried, at least, the current version is 1.2.6. (The main site was being too slow; maybe 1.2.7 just came out, but....)

FreeBSD works pretty well for me as a workstation OS; it appeared to be less of a pain to get my plug-and-play ISA sound card to work on it than it would be on Debian 2.1 (the 2.0[.x] kernel patch didn't work out of the box, and I didn't particularly want to spend a lot of time doing kernel debugging; I guess I could've tried the isapnptools stuff, but, at that point, I already had a free OS that handled the sound card, so...).

Your mileage may vary - others may find some particular Linux distribution (or some particular non-free OS, or even some particular non-UNIX-flavored OS) better as a workstation OS, or, for that matter, as a server OS, for their purpose than one of the BSDs, and others might find one of the BSDs better, and so on.

I agree, but remember that it's not wrong necessarily to put functionality first on the list of design criteria. You can always steal neat ideas from your competitors, and implement them yourself. Do note though:

Focusing on security has meant that there has been less attention towards providing features, ease-of-use, ease-of-development. The glass is legitimately half-full and half-empty.

The shape of OSS is formed largely by user/developer demand. As the demand for more security increases, Linux will see more contributions in that area. OBSD's example is critical here, and I encourage all admins and OSS enthusiasts to give it a try, since we can steal the best ideas and incorporate them ourselves..;)

Competition is good, code rot and stagnation is bad. Let's keep it friendly competition though: the goal's the same.. (and what's that goal? Making the world a place where you don't have to suffer the nonsense of M$ and proprietary crap systems for a living!)

OpenBSD is licensed under the BSD license, so porting features to Linux (GPL) without raising licensing issues can be tricky.

Linux suffers from security-related flaws, but IMHO the most serious ones relate to misconfigurations implemented by the CKI (Chair to Keyboard Interface)..

(And why not use and promote multiple OSes? Two mottos come to mind here.. 'The right tool for the job', and of course, 'There's More Than One Way To Do It!';)Your Working Boy,

Reading this guys experience of installing OpenBSD reminded me of the first time I installed NetBSD. The bewildering lack of documentation, and the archaic partitioning scheme that comes up as the default. Once installed though, I felt the same as this guy in that it was a bare bones Unix, with no cruft.

My only criticism of NetBSD (and I assume this applies to OpenBSD as well), is that the kernel co nfiguration is horrible. *BSD snobs always poke fun at the user friendly kernel configuration tools that come with the Linux source, but this is really unjustified. I never got round to compiling my own NetBSD kernel because of the paucity of documentation and the crap configuration file.

I did recompile my FreeBSD kernel on numerous occcasions, but always had that ``did I do it properly'' feeling that I've never encountered with Linux.

What more do you want from a couple of hundred words written by someone installing OpenBSD for the first time. Remember that this article is published on a Linux-centric site, and that most people use Linux as a desktop OS. As the author correctly points out, OpenBSD's raison d'etre is as a potentially secure server OS. Note that I say it is *potentially* secure - it's still up to the end user to configure it correctly. OpenBSD simply gives you an audited set of software that gives you a fighting chance of setting up an almost uncrackable server.

So don't knock this review without noting its context. I feel that he highlights the real differences between Linux and the free BSD flavours - the latters constency, economy of features and steeper learning curve.

Maybe. Except lots of the BSD API is deprecated - perhaps this is part of a move towards POSIX / XPG conformance? You have to link in compatability libraries for things like BSD C regexps, which brings back bad memories of programming on Solaris after the switch from BSD based SunOS...

``Steeper learning curve? I doubt it, unless the you're comparing redhat to them. Debian and slack can be equally daunting to a user.''

There just isn't the same amount of material avaliable for the free BSD's as there is for Linux. This is a shame as I loved NetBSD, but in the end I switched to SparcLinux simply because it performs better. (There are good reasons why Linux outperforms NetBSD - the NetBSD guys chose to code for easy portability not blistering performance on any one platform).

I can't say that I enjoyed FreeBSD though, as the version I used (2.2.7) seemed to be in some kind of limbo between BSD and System V from a programmers point of view.

As for Linux distros differing in terms of user-friendliness, I can only comment on SuSE and RedHat. RedHat is a doddle to use, but takes a lot of trimming to get rid of extraneous cruft, while SuSE reminded me of NetBSD for some reason.

You are of course completely correct in that flaws are bad both in servers and workstations. Things that are flaws on one role are pretty much always flaws on the other. The point you overlook however is that in different roles different flaws have different importances.

For example, lack of applications could be considered a flaw, as could crashing. Lets say (I don't nececcarly agree, but conventional wisdom which we are analysing has it that) Linux crashes more but has more apps and BSD has less apps but crashes less. In a workstation role, apps are critical. The benfit of more apps outweights the benefits of stability. It is not that crashing is any more "acceptable" in a single-user role, it is just that there are more important concerns. It doesnt matter how little it crashes if it doesnt do what you want!

So, we see that the "Conventional Wisdom" as you put does not say it is OK to crash a little in single-user roles, but just that there are higher priorities.

Of course, then you come to the base assumption of said wisdom which runs along the lines of: Linux has more apps, more drivers, nicer interfaces, and faster paced development but at the cost of stability and 'correctness.'

In my personal experice this is true. I use a Linux workstation every day but when I had to nuke my server (after several years of faithful Linux service) I decided to try FreeBSD. It took me a while to install it, the installation was harder (a priority I consider low on a server, higher on a workstation). But once I finished, I found much the same thing as the reviewer: everything fit together perfectly. make buildworld is an amazing thing to watch. Everything has a place and the documentation is superb. I was very pleased.

Conversely, when it came time to nuke my workstation I didn't even think of BSD. Why? Because its a shitty home-build mutt that has been upgraded over a period of 3 years. FreeBSD did not have all the drivers I needed. In addition, getting apps on FreeBSD is harder. You don't usually need gtk+ on a server, but I sure as hell ain't living without it on my desktop! (I know, gtk is in the ports tree, but it is never up to date).

In summary: you are right. Given infinite development time, there need not be a difference between server OS's and workstation OS's. But, given that there are different priorities in different roles, and given that there are limited developer-hours, having different OS's focus on different roles makes perfect sense.

I am a reasonably experienced linux user. I guess I'd call myself intermediate, leaving the term "advanced" for the "real programmers".

I decided some time back that it would be fun to experiment with OpenBSD. I was drawn primarily by it's crypto software. I was installing it on a machine that I tend to use more as a server than anything else. So desktop friendliness was not a major issue.

So first came the install. I ordered my $2- Cheapbytes [cheapbytes.com] CD, which came with an installation walk-through. This walk through made it pretty easy. I had a hiccup with my large disk drive ( due to bad bios configuration ) but a post to comp.unix.bsd.openbsd.misc fixed that pretty quickly. The partitioning procedure using the cryptic disklabel tool would have been hell without the walkthrough. However, i just did ( more or less ) what the walk through said, and it went OK.

Which raises another point -- I was surprised to find that the help on Usenet for OpenBSD is on par with usenet linux support. Far from being a bunch of obnoxious RTFM'ers, the OpenBSD crowd are by and large very helpful. I felt honoured that Theo De Raadt himself responded to one of my posts. Regarding support, the "OpenBSD FAQ" is also excellent. It is really more like a users manual than an FAQ. I highly recommend that anyone planning on installing openBSD get a copy of this prior to installation.

Once I had finished the install, I had my openBSD system up and running. I discovered a few things:

First, I was somewhat surprised that the inetd services don't go via TCP wrappers by default. I had to edit inetd.conf to make them do this. I was awfully confused for a little while regarding the fact that my hosts.deny settings ( ALL:ALL ) were not honoured. So I fixed inetd.

What is nice about the default setup is that software such as sudo, skey and kerberos is installed by default. They will be shipping ssh with it in the near future ( 2.6 ), see http://www.openbsd.org/crypto.html#ssh. Until recently, they've had obstructions to shipping this, such as patents. They are actively hacking ssh to remove these obstacles. Crypto is "integrated" into the system. For example, crypt() has built in blowfish encryption ( which is used to encrypt passwords ) See http://www.openbsd.org/crypto.html for more info.

The system also uses shadow passwords out of the box. The ports collection makes it easy to install any other secure software you might want, such as cops, ssh, rsaref, among other things. Just CD to the right directory and type "make install" and openBSD automatically installs the package, *and* looks after any dependencies -- so "make install" always works, even if you don't have some of the required packages to begin with. The ports collection is lean in terms of desktop applications, but contains a good collection of server apps.

However, it's not ideal as a desktop system. The file system is slow ( though very stable ), and the ports collection is somewhat limited compared to FreeBSD and NetBSD. It also trails FreeBSD in hardware support.

Overall, I'd highly recommend it for a user familiar with linux ( in particular, someone not scared of command lines ) who wants to set up a secure server on low end hardware.

I don't think it's quite fair to criticize the "depth" of the review. The author outright says that he's a newbie to BSD and that this is the story of his experience with it.

He tells a tale of the difficulties he had as a fairly Linux savvy person using OpenBSD for the first time, and he speaks as deeply of the benefits of the running system as his experience justifies.

I wouldn't trust hime if he went into more depth. A few days of poking does not an expert make.

BTW, I've been using Linux since 1993 (I first tried the TAMU distribution, anyone else out there use TAMU?) and just this summer installed my first *BSD system, I put FreeBSD on an old 486 on my network. I had a good experience with that. It's up and stable and I use to serve copies of my "Webmaster in a Nutshell Deluxe" and "Java in a Nutshell Deluxe" CD-ROMs to the rest of my network via NFS. It works beautifully, and I haven't had to touch the box for nearly six months now. What else do you want from a server?

So, this guys's story made me keen to try out OpenBSD and see what that could do for me.

I think that's what the article was about, rather than a comprehensive review.

Oh yeah, another commenter said (disparagingly, I think) that people who read that site are all RedHat users. I read this article and I'm a Debian user.

You're lucky. I never did get printing on my LaserJet 4m working under Linux. Turns out that you can't just:lp=9100@printer: into your/etc/printcap. So I put the server back on openbsd again so it would actually work. Yes, it's an old printer without a built-in lpd, but that's no excuse. BSD handles it just fine. Linux doesn't. (And I know, those words are ill-defined.)

As for file system speed, that's another peculiar complaint. BSD's filesystem is much faster for what I do than Linux's. Test it out by creating equivalent large trees, and running something recursive, like du or ls -R. I have directories with zillions of files in them. BSD is about an order of magnitude faster for this than Linux.

And why do you say that for a desktop machine, the filesystem speed is important? Is this different from what you want in a non-desktop machine? Why?

As for networking, it seems more sensible on BSD. I find that the many Linux versions all have their own little sillinesses that you have to sniff out. They also seem need an extra route that I don't need to remember to do in BSD.

In fact, there's absolutely nothing I want to do that I can do in Linux that I can't do in BSD. Sure, there are kernel threads in Linux, but it's not like they're as robust as on Sun or SGI.

As for games, I find that BSD comes with a lot more than Linux does, which is basically nothing at all. It's nice to be able to just type rogue and it run right out of the box.

The ports stuff is much saner than anything I've ever seen for Linux. I don't understand why people expect absolutely everything pre-installed, or why they always want binaries. It's very scary. There's something very comforting about having a 100% source system, and one where you just type make. You want to know how to make rm stop asking stupid questions? Just cd/usr/src/bin/rm/ and look at rm.c sitting right there. Don't like something? Edit the file, and just type make.

And then there's the fact that/sys is there again, and things are where you expect them to be.

And then there's the fact that all binaries and libraries come with man pages, something that all the Linux operating system bundlers have completely screwed up.

I guess what I'm saying is that BSD is much saner and coherent -- and familiar -- if you're a long-time Unix user than Linux is. Then again, I've been using BSD since 81 or 82, so it's not surprising it makes more sense to me than then Winix stuff you see in Linux.

I'm not sure what a "desktop application" is. I guess this is probably some kind or program Some kind of publishing or simulation or CAD program? Every time I hear "application", all I can think of is grauitous bloatware.

I'm serious, and I'm not trying to be obtuse. I'm a Unix programmer, not a starry-eyed neophyte in search of eye-candy. I have mailers, newsreaders, web browsers, web servers, editors, admin tools, a complete development environment, etc.

The only bloatware I've got installed on the openbsd systems is netscape. It's also the only non-source program here. I've tried mozilla, but it crashes all the time. I also offer users amaya and lynx.

As far as bloatware goes, I also installed enlightenment and gimp, mostly as a test to see whether I could. And yes, there was no problem. I've a friend who's an Apple user, so put gimp up for them. And enlightenment was semi-interesting, but I've gone back to tvtwm, which suffices for my purposes. I don't know whether these are what you call "desktop applications" or not.

As for/usr/ports, I get this

openbsd% ls -d/usr/ports/*/*/ | wc -l 642

Although I admit I haven't done an mcs get lately. My only FreeBSD account doesn't have/usr/ports properly populated, so I can't check. What's it like there?

It seems to me that it's more important for a machine that has many users to be fast (what kids these days call a "server") than it is for a machine that serves the needs a lone user (what kids seem to call "clients" or "workstations" or "desktops") to be fast. After all, slowness in a shared resource hurts everyone who's sharing it.

As for file system speed, what do you mean? Are you saying that FreeBSD isn't using FFS, or that OpenBSD isn't? If they're both using the regular FFS, why is there a difference? Have you benchmarked this? Are there published numbers? My only experience is comparing OpenBSD and Redhat for ftw stuff, and the former came out way ahead on a hugely bushy file system.

I don't see the problem with the Linux documentation that so many people seem to be complaining about.

First, there's quality. Let's say you'd like to learn how to program a tty device. On Redhat, I get 66 lines of documentation for tty(4), but on OpenBSD, I get 299 of them. There's a lot more where that came from.

openbsd% find/usr/share/man/cat4 -type f -print | wc -l 371

The same query on my Redhat system came up with only 50 files. And the mere presence does not suffice, as I already showed you with tty(4).

Second, there's simple correctness and completeness. A virgin Redhat installation is so full of crap in the manpages that you want to pop somebody one. They've got catpages installed alongside the manpages (e.g./usr/man/man1/mailq.1) They've got missing.so links -- try getting a manpage for getnetbyaddr(3); it doesn't work, and if you look, you'll realize why. They've got hundreds of broken SEE ALSO links, as well as thousands (well, around 1700) of missing manpages. They've got a few dozen or so that are simply wrong, all thanks to the Fearless Leaders from you-know-where. It's really completely incoherent.

If you go to bugzilla [redhat.com], look up bug numbers 6043, 6044, 6046, 6049, 6255, and 6315. Redhat has been very responsive to these bug reports. I've even given them a bunch of programs to help with this, but the current situation is pretty darned embarrassing to anyone used to a proper Unix release. (Anyone interested in noman(8), cfman(8), or scatman(8) can pull them from bugzilla or send me mail.)

Like the author of this review, OpenBSD was also my first. I had a Boeing-surplus Sun station I was running on a shoestring budget for an college organization I was in, and when the hard drive blew up before I could procure a back-up device and I didn't have any installation media (I know, I know... playing with fire), I found myself in the un-enviable position of having to find a replacement OS to put on the replacement hard drive. And yet, I was on a shoestring (and spit and chewing gum) budget... so I did some checking around. Wanting to try the OS before dedicating my precious collegiate hours to the installation process, I found that OpenBSD would run on both Sun and Intel platforms, and that there was really good Sun binary compatibility. Actually, I was tossing coins between NetBSD and OpenBSD, but the security audit was a good selling feature.

So I proceeded to install OpenBSD on my 4 year old 486 from floppy images. (I didn't have the funds to buy the CD, either, but I did have some old AOL promo disks.) After a day and some of fiddling, I had the system up and running, although I had many of the same troubles as the author of the review, but without the prior Linux experience to draw upon. I installed X11 and a few other necessary programs, and ba-da-bing, it ran fine.

About a year later, after I was no longer in charge of that organization's computer woes, I transitioned to FreeBSD, since it had better focus on the Intel platform and in particular supported the odd arrangement I was resorting to to drive my CDROM. Still, for a first foray into the wild, wild world of installing and running UNIX from scratch, OpenBSD was pretty good!

quick example. About 6-9 months ago, there were maybe 40-60 people in #FreeBSD on efnet at a time. This number has grown to 170-240 on average. This is similar to the growth in the #linux channels except at a lower order of magnitude. I think we'd have more people in there if the ops didn't get pissed off when someone asked something particularly stupid:). The linux channels on the other hand seem to be more oriented towards setup help (there are some cool people in #FreeBSD ready to help though !).----------

a) check to make sure your video card is supported by xfree first b) run/stand/sysinstall and go to post install operations -> install additional distributions -> whatever you want on the x menu c)once that's done, go to post install -> configure xfree86 server from which it run XF86Setup (or the command line util if wanted). d) once you have that running, then post install -> Setup XFree86 Desktop and install your window manager of choice (gnome + enlightenment or afterstrep [doesnt work very good in bsd], windowmaker, fvwm2, or KDE (i'd recommend kde + blackbox or windowmaker or just plain KDE).

All linux XFree setup's I have tried have been similarly intuitive..----------

My install nightmares over, I began to explore the system. What I found impressed me. The distribution was quite minimalistic compared to a distro such as Red Hat Linux. It was a nice feeling to know what every binary on my box was used for. I had the impression that every file and every directory had been placed with a distinct purpose. The layout seemed carefully contemplated. Unfortunately, I still don't know what many of the binaries on my Linux box are for, and they are often scattered around almost randomly. Instead of careful design, I feel like my distribution was simply trying to fit the most free software possible onto my hard-drive. I don't mind this behavior on my workstation, but I definitely don't enjoy cleaning up cruft from my servers! OpenBSD handily beats Linux here.

Right on! That was one of the hardest things I encountered when getting used to Linux. Binaries in/bin,/sbin,/usr/local/bin, etc. In thinking of a better way to set up an OS (yeah, like I'm gonna invent an OS) I figured most binaries will need:

Source (of course) for available hacking/patching

Docs/manpages

configuration files/scripts

the binary itself

other stuff

There's two ways to organize this, either every binary has it's own location (in one distinct repository) under which all of the above is included, or the above categories are divided into several locations, such as/bin,/conf,/src, etc. Which do you think would be a better model? I'd vote for the latter, as long as it was easily predictable where things were.

First of all - I love OpenBSD. It's made my life as a sysadmin MUCH easier.

Having said that, I wouldn't want Linux to pick up it's development model. Actually, Debian is almost there. The BSD groups are incredibly picky when it comes to what get's put into their OS. The kernel development is a much slower, and much more mature process. If Linux worked that way, we wouldn't see 2.4 until 2005.

A line-by-line audit of Linux's code wouldn't be bad idea, but the state of that code changes so frequently that I don't think it could be done properly without affecting the development process.

Several posters have espoused using some flavor of BSD for "servers", but some flavor of Linux for "workstations". This viewpoint is one that you hear repeated so often that it seems to have taken on a life of its own. But what essential criteria are being used to arrive at this position? Proof by repetition has no place in the technical community. Is there any substance to this mantra, or are we just hearing the unexamined echoes of well-trained and well-meaning parrots?

Precisely what features are desirable in a "server"? What features are desirable in a "workstation"? What even is the difference between a "server" and a "workstation"? Does optimizing for one of these environments pessimize-- or at least compromise--the other situation? Is there some technical feature that you really want to have in a multi-user situation that you don't care about in a single-user one? What about the other way around?

Here's my conjecture: there is no difference here. You want the same in both, because a soi-disant single-user Unix workstation is still a complete multi-user environment with all the attendant issues thereof.

A system's inadequacies appear more acceptable in a single-user system only because they can thereby annoy only one person at a time. In a multi-user situation, such problems are less tolerable because the pain is multiplied by the number of individuals affected. But inadequacies they remain.

Just as you want a solid, sane, robust system for a computer that provides services for an entire department, so too do you wish the same coherence and correctness on my very own computer that you are the principle user of. For example, you don't expect to reboot a server just because you install some new software, and neither do you expect to do the same on my own machine. Granted, Unix isn't stupid here, the way the Evil Empire is. But by allowing sloppiness in a "single-user" environment that would never be tolerated in a "multi-user" one, we risk relegating ourselves to a plane of Hell not so far removed from the one currently inhabited by gibbering victims of the Horror Out of Redmond.