FreeBSD Documentation: An Interview with Tom Rhodes

An Anonymous Coward writes "FreeBSD has been known for excellent documentation and here is a rare sneak peak behind the scenes of the FreeBSD document project with FreeBSD's very own Tom Rhodes."

Comments

Only slightly OT

[numbski]

I have a question for those interested in FreeBSD documentation:

Let's say you have a production environment running FreeBSD 5.x (I know, boo, hiss, only -RELEASE, not -STABLE...blah blah blah), and with the upcoming release of 5.3-STABLE (my understanding anyway), how would you recommend a minimal downtime upgrade?

I have 2 nameservers running the stock Bind8, 2 MX's running stock sendmail. One 'users' box running Sendmail with spamassassin and spamassassin milter, along with apache2 and squirrelmail for webmail.

None of these boxes have the full sources installed, and in the past I've taken the boxes down and done a binary upgrade from CD. Is this the fastest method?

Re:Only slightly OT

[feargal]

I usually upgrade from source. You don't need the current sources to upgrade, just the new ones, so grab them with cvsup.

I do the initial builds offsite and usually well in advance (perhaps leave them to work on a Friday evening).

1. make buildworld
2. make buildkernel

Once onsite, I:
3. make installkernel - takes a few minutes, doesn't count towards downtime.
4. reboot
5. mergemaster -p - takes about a minute
6. make installworld - takes maybe 5 minutes at most
7. mergemaster - this takes the longest - I usually manage it in about ten minutes, as I've become pretty familiar with it, and make the right decision pretty instantly.
8. reboot

I've timed myself, and I end up with 15-20 minutes downtime, depending mostly on the speed of the machine.

Going more off-topic, but I had an idea on how to make this process faster, and to make mergemaster much less scary.

Most of the files that are affected by the mergemaster process are rarely actually changed. On a stock server, you'll probably only ever change files in /etc/mail, /etc/namedb, /etc/ssh, and perhaps one or two other file. All the rest of the files are usually unchanged by the sysadmin. The mergemaster process however asks you if you want to upgrade all the files that have changed in CVS. This takes a lot of time and involves repeating the same keystrokes, and is probably the source of most accidents: shift-G, i, shift-G, i, shift-G, i, "oops, shouldn't have overwritten that one!"

It should be trivial to, pre-upgrade, traverse /etc, extract the version numbers, download their originals from CVS, diff the two, and build an "auto-list" of files which have never been altered.

When mergemaster is run, it can then automagically upgrade all of the files in the auto-list; if nobody saw fit to change /etc/mtree/BSD.usr.dist, chances are the new one will do just fine. Meanwhile, the sysadmin only has to think about that matter to him.

Also, prior to doing the upgrade, he would be able to get a list of files which he *has* changed, so he can figure out what exactly he was thinking when he decided to hack /etc/rc.d/initdiskless to bits.

Any reason this wouldn't/shouldn't work? Obviously mergemaster should give Big Bloody Warnings before using the list. I reckon I'd save at least 25% of my downtime doing this.

I have been impressed...

[brilinux]

As someone who has used multiple Un*x-like OSes, such as FreeBSD, OpenBSD, Gentoo Linux, Debian GNU/Linux (and I am not a zealot for any of them - imagine that!), and others, I have found that if I want to know about saomething or how to do something, FreeBSD has always been the best at having the information availiable. It is very easy to find what I need to know, and everything seems done very logically. Good Job, guys!

For Such A Critical Yet Thankless Job...

[devphaeton]

Thankyou to all the folks that have created the world-class documentation system to go with the world-class OS that is FreeBSD.

*thumbs up*

Re:Tom Rhodes

[Anonymous Coward]

Please ignore this troll. It's the same guy who has been pestering every *bsd (yes, even NetBSD) announcments trying to discredit FreeBSD developers. He usually goes on to say just how FreeBSD devs hate Dragonfly, how they unfairly kicked out Matt, and so on.

Sometimes he links to a message posted by DES on FreeBSD-advocacy in his signiture. If you take the time to see how that thread started, you'll see that the original "quesiont" was quite rude, and follow-up messages from the same person were written in a "I'm a famili member of the former Nigerian royal familiy and want to deposit large sums of money" style. Also if, you follow the thread further, you'll see this reply from a FreeBSD developer:

> BTW, I've spent a lot of time looking at the DragonFly approach, and I met
> with Matt for quite a while at USENIX to talk to him about the approach. I
> have a number of concerns about it -- I think the premise is very
> interesting, but that the results aren't yet there to prove the model. In
> particular, there's a huge volume of code in their system that has not
> been addressed, and a lot of complexity that will need to be handled
> before the SMP primitives they're using have proven that they offer the
> desired performance advantage. We have the opportunity of using a hybrid
> model, and have been exploring some of the ideas present in DFBSD (and,
> one should point out, many other SMP systems).
>
> A lot of other systems have opted to use elements similar to those
> primitives, but in a much more limited way due to the performance costs.
> For example, locking services into particular CPUs prevents the scheduler
> from balancing load between the CPUs in an service-transparent way. In
> the DFBSD model, load balancing must be implemented separately for each
> service, requiring extensive modifications to the services. I.e., the
> model may indeed offer benefits, but the cost of doing the work will be
> high, and the time to complete it long. We'll adopt elements of the
> design as they prove to make sense, as we do with all other open source
> operating systems (and they do with us!).

For your interest, Matt still posts occasionally to -current list, in fact, he even helps out a bit here and there. This troll's problem seems to be with DES, PHK, Bosko, but he is ready to extend his warm words towards anyone, even, it seems, to someone associated with the documentation project. Oh, btw: you'll see the same message by Doug-Furlong Smorgreff on Osnews as well. ~molnarcs