[geeks] State of the BSDs (Was: [rescue] Transplanting a Sun Fire V210 motherboard - PSU requirements?)

[microcode at zoho.com]

On Thu, Feb 28, 2013 at 03:06:29AM -0500, Mouse wrote:
> >>> The tools and package management are finally to the point doing
> >>> this is very close to painless.
> >> Oh...are you under some kind of delusion that nobody ever runs
> >> anything but OS-supplied packages?
> > No, I'm not under any delusions of any kind as far as I know.  I
> > spent enough years compiling everything from source that I actually
> > prefer not to use package management at all.
> 
> Then I'm rather puzzled why you think that good management of
> _anything_ by the OS supplier can mean that porting an existing
> codebase to a new version will be painless.  The only way that can be
> guaranteed is to not change anything; the only way it can be made even
> _likely_ is to change little.

It depends on what's being changed. If you're careful (in the OS) to
preserve existing interfaces then application code shouldn't break. There
are good ways and bad ways to add new features. It doesn't necessarily
follow that new features have to break old code, although in UNIX in
practice it seems to happen more often than it should. A lot of that has to
do with shared libraries. But a lot of it has to do with insensitivity to
existing code when making "improvements" to base. I think in the latter area
OpenBSD appears to do a good job, certainly better than average.

If your application code exploits loopholes or does things in non-standard
ways that's also a place for problems to happen. If you're talking about
system code, then it's inevitable that you'll be more affected by changes
than application code would be. There's nothing new about this, as you know.

Specifically to your question, since OpenBSD's ports are bound to a release
they do better than average in not breaking the ports they have. That
doesn't mean nothing breaks or that everything you want is in the ports tree.
But if you stay within the system as it's meant to be used, as much as
possible, Open seems more stable and things work better for me than they did
on FreeBSD or Net.

> 
> > But in some cases, it is easier to use it.
> 
> Perhaps, if you're lucky enough that everything you care about is
> represented there.  I've got well over a hundred and fifty thousand
> lines of code to coax into building with each new release I care about.
> As far as I know, none of it is in anyone's package system (unless you
> count the way I manage it as a package system, I suppose).

There's nothing anybody can do about a situation like that. All I'm saying
is I feel OpenBSD's ports tree that is bound to a release is a better
solution than FreeBSD's rolling ports tree, for example. And since Open
rebuilds all the ports and tests many of them for each new release, you're
less likely than normal to run into application breakage on stuff they
build.

You can minimize the pain of upgrading and keeping current if you use their
packages and ports as much as possible. Then all you have to do is worry
about the stuff you built outside the system. That eliminates most of the
upgrade issues unless the majority of what you run isn't available in
ports. OpenBSD's sysmerge does a good job of merging new config files and
showing you diffs of the changes so you can make your own decisions.

On the system I work on for my job, we have code that's been running for 25
or 30 years and never breaks. We don't use shared libraries and the OS is
changed very carefully not to break old code. I don't like the way things
are done in UNIX and I'm the last to defend it, but that doesn't mean
certain UNIX implementations aren't better than others, or that people
working on certain implementations haven't done a good job trying to
maintain stability and sane development, and been more successful with that
than other projects.