Do we need this junk?

Nikolas Britton nikolas.britton at
Fri Apr 6 19:43:33 UTC 2007

On 4/6/07, Ed Schouten <ed at> wrote:
> * Nikolas Britton <nikolas.britton at> wrote:
> > On 4/6/07, Ed Schouten <ed at> wrote:
> > >* Nikolas Britton <nikolas.britton at> wrote:
> > >> Well based on the stats I've posted maybe it's time to split FreeBSD
> > >> i386 into two platforms, one for embedded/legacy systems and one for
> > >> modern systems? The needs for each type of system are diametrically
> > >> opposed, and the modern ones make up the majority of deployed systems.
> > >> Perhaps FreeBSD i786 or IA32, with the minimum target being a
> > >> Willamette based Pentium 4, aka SSE2?
> > >
> > >So what's the practical advantage of that? That would only break stuff.
> > >Compiling a kernel without these options practically does the same
> > >thing.
> > >
> >
> > Break what?
> Renaming a platform is the root of all evil. Think about the big amount
> of ports and source code that just check for $arch == "i386". That's the
> reason the i386 port is still named i386, though it doesn't even support
> i386 at all (got removed in 6.x).
> > The primary reason for doing this is optimization and simplification
> > of support / development.
> Indeed. You'll simplify development, because half of the developers is
> unable to run the bloody thing. Just run FreeBSD/amd64 if the legacy
> bits upset you.

That's not true. If you look at the stats I posted over 58% of the
systems have SSE2 support, compared to the 20%* with 64-bit

The legacy bits don't upset me, what upsets me is sacrificing
performance so we can  support a minority of legacy systems. IIRC? we
could recode the Kernel for SSE2 math if the processor was guaranteed
to have that SSE2. SSE2 adds 214 new instructions to the existing x86
instruction set. The problem with 64-bit FreeBSD is performance, on
average its slower than FreeBSD i386 and FreeBSD i386 is already quite
slow without custom optimizations. i.e. lots of recompiling... New
users frequently get themselves into a big mess because it takes years
of knowledge about FreeBSD internals to make it fast without breaking
it. This turns new users off and can create support problems.

*Edu. Guess, The stats were not setup to measure 64-bit support, I
discarded the information that wasn't being measured.

More information about the freebsd-current mailing list