Painlessly Update FreeBSD

boarder8925 writes "Over at BSDnews, Steve Wingate has written an article on how to easily update FreeBSD. Wingate begins his article by saying, "One of the greatest advantages that *BSD has over other Unix variants is the cvsup/make world process. Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system. The cvsup/make world process allows you to update your system at any time. I'm going to show you how to make the process as painless as possible." The article discusses the following: installing CVSup, choosing a cvsup server, configuring make.conf, and, finally, performing the upgrade. The piece is also available as a .pdf file."

Comments

This is different from the cvs guide

[RLiegh]

in the handbook how?

Anonymous Coward's Guide to Updating Debian

[Anonymous Coward]

# apt-get update; apt-get dist-upgrade

Wasn't that hard?

Re:Anonymous Coward's Guide to Updating Debian

[rsax]

Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date. FreeBSD isn't. It's a stable operating system with upto date third party software delivered using the ports system. I've said this before and I'll say it again since this Debian comparison has been brought up.... I hear this argument from Debian advocates a lot: "Do you want a stable server or do you want bleeding edge?" Well with FreeBSD I get stable servers and still have packages that aren't a year or two [or sometimes more] old...... it is possible. And before anyone recommends that I run Debian testing instead please remember that the Debian Security team claim that they don't support anything besides the stable releases. I could use a Debian stable system and then mix match packages from unstable or testing and risk instability in the end or higher maintenance due to no security alerts from one source but then why not use FreeBSD instead in the first place?

That's the easy solution?

[cperciva]

If cvsup && buildworld && installworld is the easy solution, I wonder what he considers this to be:

freebsd-update fetch
freebsd-update install


Yeah, ok, FreeBSD Update is only about tracking the release branch. But really, this story just covers the standard technique which people have been using for... well, longer than I've been using FreeBSD.

too many dependencies

[hak1du]

Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.

The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.

The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.

Re:too many dependencies

[josepha48]

"Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me."

No kidding. My NetBSD box taks hours to compile all these packages. If all you want to do is upgrade xscreensaver, all you have to type is make update ( or is it upgrade ). But what happens in the background is that it probably has newer requirements, like an updated gtk, which depends on pango updates, and that depends on .. and so on and so on, and then suddenly updating one program becomes updateing the WHOLE gnome desktop and compiling from sources. On an old 233Mhz that is a long time. But hey NetBSD and FreeBSD install on on old 233Mhz with only 64Megs of RAM, Redhat doesn't, ( debian does though ).

I agree "The choice shouldn't been between huge amounts of recompilation ..." but I can't see having the whole GUI using JITs. Also most of these programs use dynamic binding.

See the problem is that the maintainers of these packages, upgrade the requirements of the packages based on new features in these packages or just because it is the latest in the release tree and assumed to have less bugs. IE. xscreensaver probably would have compiled fine in teh above example with the gtk onn my system, but the Makefile for it has a requires gtk 2.2.x+ or something like that in it which it then checks to see if it is installed on the system. It should really have done, if gtkversion == 2.0 compile with gtk 2.0, and leave our whatever features that it is missing. Chances are there are none that require gtk 2.2 and 2.0 wont work just fine. However if it was gtk = 1.2 then update. A better example is programs that still use gtk 1.2. Is there really a difference between gtk 1.2.10 and 1.2.10nb2? Probably not enough that you are required to upgrade all the programs on the system. They should add an option, and call it make update_all which updates ALL the dependancies and then the default behavior should be make update just this one program. That's what the problem is with this compile stuff. I use Linux, NetBSD, FreeBSD, Windows, Sun, and Mac. They all have their plusses and minuses. It really depends on what you think is important.

Why is his method special?

[hayds]

When I first saw the headline about "painlessly updating", I thought this might be a great article about some new innovative way to update. Its not really anything new or interesting though, the whole article is basically saying: "cd /usr/src && make world && make kernel && mergemaster will update you system"

Not wanting to sound rude, but no shit sherlock! Yes, this is a painless way to update your system. It is also the way to update your system, as is very well spelled out in the excellent FreeBSD Handbook so I'm not sure why it warrants an article....

Maybe its just me but I think an article about portupgrade or something would have been more useful.

Re:And the advantage Linux has over BSD...

[Khazunga]

Faster, you say? I'd say numbers contradict your impression.

You can say a lot of good stuff about *BSD, but it currently does not match the quality and quantity of great minds work that is being put into the linux kernel.

Re:And the advantage Linux has over BSD...

[Khazunga]

Quick summary:

• socket(2): All systems presented less than O(n) values, with call times measured in the 10k CPU cycles range (extremely short execution time). Advantage to FreeBSD
• bind(2): O(1) scaling by Linux 2.6 and FreeBSD with no clear advantage for either.
• fork(2): O(1) scaling by Linux 2.6, with a severe scalability issue for FreeBSD
• mmap(2) with subsequent touch and read: Clear win by Linux 2.6 due to FreeBSD mmap times scaling O(n) while Linux scales O(1)
• HTTP request operation sequence (connect plus serving) Both scale O(1) with similar answer times

From that, I read a tiny FreeBSD advantage in the socket call (in terms of absolute execution time) and two FreeBSD scalability issues: one rather serious, and one O(n) versus O(1).

Again, one can't be less than astonished by the Linux kernel development over the last two years. Not that one would notice the difference between Linux and FreeBSD on everyday use, or less than stressfull server deployments. They're both in the same league but, as of now, Linux is more polished. Scaling O(1) for almost every algorithm in there is amazing.

Re:"unlike most linux distributions"?

[Brandybuck]

If that's true, then how come every time there's a new linux kernel version, hordes of slashdotters come out querying when it's going to included in their distro. With Linux you either have to wait until someone updates a kernel package (or emerge script), or go grab it and built it yourself manually. It's not going to happen instantaneously.

That's the essence of what the article blurb is saying. No need to get all defensive about it. You chose to use a system that someone else integrated together for you from many different disparate projects. You can't expect that integrator to provide instant updates to every part of the base system you're interested in. For most distros a new kernel version takes a few weeks to make it into an upgrade package.