Posted
by
kdawsonon Monday March 26, 2007 @06:41PM
from the sometimes-a-cigar-is-just-a-stogie dept.

Lawrence Teo writes "Unlike other operating systems, patches for the OpenBSD base system are distributed as source code patches. These patches are usually applied by compiling and installing them onto the target system. While that upgrade procedure is well documented, it is not suitable for systems that don't have the OpenBSD compiler set installed for whatever reason, such as disk-space constraints. To fill this gap, open source projects like binpatch were started to allow administrators to create binary patches using the BSD make system. This article proposes an alternative method to build binary patches using a chroot environment in an attempt to more closely mirror the instructions given in the OpenBSD patch files."

Funny, but I left the Linux world a few years ago because I got tired of wasting time managing the OS and fucking around with trying to figure out what changed this particular kernel release or what the new packet filter is going to be this year, or if we'll be using tmpfs or udev or whatever the fuck else as a memory filesystem, or why some stuff that used to work doesn't anymore. Etc, etc. ad infinitum.OBSD is so fucking cohesive and stable compared to Linux that I can't imagine ever wanting to go back.

There's this other OS you might have heard of, it's called "Windows". Stupid name, I know. They distribute their patches as binaries. I also heard there's this other OS, it's something like "Tiger" or "Panther" or something and they do the same thing.

I know every fourth word out of Theo's mouth is a slight against Linux, but that doesn't mean everyone related to OpenBSD does this.

Without wanting to start a fight or anything, I genuinely don't see how the grandparent is slighting linux here. You can for a lot of linux OSes get the patches as source code. Sure, Windows doesn't, but that's not linux, which the grandparent specifically asked about. As for Mac OS, I don't know whether you can get the patches as source, but I imagine not.

The kernel and low-level stuff is open, so I suppose if you are so inclined you can download the latest darwin sources/patches and compile them. The GUI-type stuff is closed, though, so binary patches for that.

OpenBSD is primarily used for firewalls. The purpose of a firewall is to do essentially nothing 'cept route and filter packets. As such, the cheapest least broken hardware is typically used. Some people (*cough* Steve Wozniak *cough*) even see embedded firewall devices that run OpenBSD. They run entirely off flash memory.

Thats a questionable statement, that OpenBSD is primarily for firewalls.I'm writing this on an OpenBSD 4.1-current laptop (IBM A31p ThinkPad) andhave used OpenBSD exclusively since 2001 for all my desktops. A lot ofpeople are discovering that OpenBSD does really well as a desktop. Withthe introduction of 4.1, Open Office is supported, not to mention KDE,media stuff, a really outstanding population of wireless cards, etc. Ithink there are people who think of OpenBSD as a just a firewall; asgood (well,

I currently use Debian on my desktop; I used to use FreeBSD. Given that both of these are aimed at being general purpose operating systems, whereas OpenBSD is at least perceived as being primarily a firewall/server operating system, why would you choose to use OpenBSD on your desktop instead of something more general purpose? What advantages and limitations does it have over GNU/Linux distributions or FreeBSD as a desktop? Is it something along the lines of you know it from your firewall so you'll use it on

Yup. We do this at work (no link because I'm not spamming). We sell OpenBSD firewalls on minimal hardware (about the size of a broadband router, low power enough to be fanless), and then sell various services on top of that. You can do a surprising amount.

We use flash memory, and the space and rewrite cycle requirements for compiling on this are prohibitive.

Some people (*cough* Steve Wozniak *cough*) even see embedded firewall devices that run OpenBSD. They run entirely off flash memory.

As do I, if I look across the room right now. A mini VIA machine, bought originally to play with, that now boots a stripped-down OpenBSD off a read-only mounted IDE-connected CF card, running firewall & local DNS.

And the point of this article is *stripped down*. Unfortunately, the writer gets it all wrong, re-invents someone else's wheel, and doesn't really solve the prob

The submitter is just pumping up clicks to his own site. You'll notice that he's also the author of TFA. I don't see that this is a particularly useful system, since you'd just be building binaries on another box anyway. If you're going to do that, you might as well just build an upgrade CD and upgrade through the normal process.

Puff the Magic Blowfish, lived in the seaAnd frolicked in the SCSI disk in a land called Bee Ess Dee.Little Theo de Raadt loved that rascal puff,And brought him threads and interrupts and other fancy stuff!

The article describes a technique which is in large very inefficient, and wasteful. It is analagous to the notion that a process must be completely copied on fork, however this is not true. Typically the pages used by a child process are copy-on-write, and are only duplicated as the child writes to them. To see the analogy, consider that the article describes this basic process:(1) Create a new directory (the author creates something in/var).(2) Unpack a brand new OpenBSD distro and source distro to thi

Most open source operating systems deliver their patches primarily as source code. I know Free and Net BSD and Linux provide source based patches. In fact, if you track the FreeBSD security announcements and errata information, you download a source code patch in the form of a diff file. To apply the patch, simply make certain you have downloaded the source code in the/usr/src directory and use the patch command. From there, the diffs are applied and you can run make to recompile the patched section. The commercial Linux vendors like Red Hat and SuSE provide binary patches for convenience purposes. The author of this article really should do more homework before making the statement that he did. Personally, I like the patch and compile method. I do know that this is a more secure way of supplying patches because you can read the source code and it makes delivering malware harder. I like to see what is going on behind the scenes.

Hey, that's kind of cool. I didn't know about freebsd-update and I am a FreeBSD admin. That's the cool thing about UNIX like systems. There is always learning. I usually do a cvsup if I want to upgrade the whole thing. For just bugs in BIND or other programs, I grab the patch file.

This is a lot like existing techniques, such as Gentoo's installation sandbox: first, a package is installed in a temporary file system, and changes made during the installation are then merged into the live filesystem (if installation was succesful, and none of the newly added files conflict with files already installed).

Furthermore, the FreeBSD manual recommends a similar procedure for automated building of package lists (lists of files installed by a package): create a regular port, install it into a temporary copy of a base filesystem, and use mtree to figure out what files were modified during the installation process. In this case no chroot environment is used, since ports are expected to honour the installation prefix (given in PREFIX).

So it's a pretty well-established technique; I'm not even sure using it to upgrade the base system is novel: as of late, FreeBSD provides binary updates to its operating system in addition to the traditional source upgrades (and binary releases), although I'm not sure how these packages are created.

I consider OpenBSD my primary desktop OS. Now, having used systems like Debian, I must admit yours is a question that's difficult to answer. I probably can't come up with one that is compelling for all people. But I can take a stab at how I feel about the issue.If I could use a few words to describe the interaction of base system packages on Linux with the equivalent on BSD, I could describe the BSD scheme with words like "small", "simple", "cohesive", "compact". Although many different software package

This sounds like a total hassle. What's wrong with proper package management? (I'm not trying to troll, I'd really like to know!)

The only thing wrong with proper package management is that OpenBSD doesn't have it, so you're going to get lots of touchy-feely responses about how it feels better, or is about some matter of taste to do extra work that someone else has already done.

Fortunately, FreeBSD has something _almost_ as good as Slackware's packaging system (which isn't very) so it shows that at least a f

The *BSDs package management is better than any other I've seen, and far better than Slackware's pkgs, which don't manage dependencies at all... OpenBSD just doesn't use packages for the base system (dist sets instead), and doesn't provide updated binaries (for manpower reasons), only source.Maintenance actually gets easier, the more machines you have. If you need to build from ports for some reason, you only have to do it once, and can distribute the generated packages across as many systems as you want.

Maintenance actually gets easier, the more machines you have. If you need to build from ports for some reason, you only have to do it once, and can distribute the generated packages across as many systems as you want.

Of course it should get easier. If maintenance got harder then nobody would use FreeBSD. You're missing the point. If I build the

This is the beauty of peer review, especially from a group as vicious as Slashdot. I imagine the author of this process was so pleased with himself and excited to share his ingenuity with the world, only to submit it here and have his ideas stomped, blasted, toasted, dragged through mud, and rendered to pieces. Not that I would suggest we do anything different, but sometimes I cannot help but to admire the crucible that is public forum.

Gerardo Santana worked on a project implementing binary patches for OpenBSD [sourceforge.net] at least since 2001. His code is quite reliable, IIRC he basically lacked the needed machines to create the patches for all the OBSD officially supported architectures.