HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

Paul Allen pallen at ugcs.caltech.edu
Thu Aug 17 16:24:11 UTC 2006

>From Divacky Roman <xdivac02 at stud.fit.vutbr.cz>, Thu, Aug 17, 2006 at 04:01:22PM +0200:
> 1) leave it as it is (ie. as what will be commited shortly), this means runtime
> checking for osrelease sysctl and behaving according to it
> 2) introduce option LINUX_24 or something like that to make this a compile time build
> 3) remove the 2.4 completely saying that "if you want 2.4 emulation downgrade fbsd as well". 
> notice that this is 100% ok because linux itself doesnt support 2.4 emulation on 2.6 kernel.
Actually you shouldn't need runtime checking so much as load-time reading of the elf

Let me say that there is something amazing about FreeBSD:
  the ability to build a kernel with COMPAT_XX and run old FreeBSD binaries

In some ways this seems like a page straight out of POLA.

Linux can be a major pain; even in a maintained distribution ala Redhat the system
seems to EOL in the blink of an eye.  I had a customer once who had a mix of old
binaries and obscure requirements (e.g. pm3).  I put together a vmware image of the
necessary environment: just the right kernel, just right version of glibc, etc.

Most of the stuff that gets run through linux emulation on FreeBSD is for desktops
and isn't mission critical... still I'd get pretty annoyed to one day discover that
I needed to buy new versions of Matlab and Mathematica...

On the other hand developer resources are scarce; it would be much better if I had 
FreeBSD binaries of those programs :o)

The linux model works when:
1) you have the source for everything
2) all the source is actively maintained to keep abreast of API changes
3) you are free to recompile and replace any part of the system at a whim

Or you can run Debian and wait for three year cycles :o)

   (okay,okay, I'll stop picking a fight now; 
    hope everyone takes a little ribbing in good fun)


More information about the freebsd-current mailing list