Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2007 08:02:16 +0100
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        David Schultz <das@FreeBSD.ORG>
Cc:        Brooks Davis <brooks@FreeBSD.ORG>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG
Subject:   Re: RFC: libkse*.a in 7.0
Message-ID:  <20071211080216.pb3b95teoggko00o@webmail.leidinger.net>
In-Reply-To: <20071210223838.GB16598@VARK.MIT.EDU>
References:  <20071128211022.GA74762@lor.one-eyed-alien.net> <20071128213947.Q7555@fledge.watson.org> <20071210192533.GA15728@VARK.MIT.EDU> <20071210220854.07e02f1f@deskjail> <20071210223838.GB16598@VARK.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting David Schultz <das@FreeBSD.ORG> (from Mon, 10 Dec 2007 =20
17:38:38 -0500):

> On Mon, Dec 10, 2007, Alexander Leidinger wrote:
>> Running Solaris 8/9 programs is not supported by SUN on Solaris 10. It
>> works in some cases, but it doesn't work in some other cases.
>
> That's not true. It is supported. See:
>     http://www.sun.com/software/solaris/programs/abi/
>     http://www.sun.com/software/solaris/programs/abi/sag.xml
>
> In theory, a SunOS 5.0 app will still work in SunOS 5.10

The important part is the "theory" word...

I work in the office of SUN in Luxembourg, and one of our ideas for a =20
client was to run a Solaris 8/9 in a zone of a Solaris 10 as a =20
replacement for machines with Solaris 8/9. As we have a service =20
contract with our client, we have to take some business constraints =20
into account. And one of those business constraints is that Solaris =20
8/9 in a zone of Solaris 10 is not supported, as the kernel interface =20
(syscalls) changed in an incompatible way.

> Of course, in practice, perfect binary compatibility is too much
> to ask for. It's possible to write programs that notice that

So far we handled this good in FreeBSD.

> different releases aren't bug-for-bug compatible, and if you
> statically link your binary or use unsupported ABIs, you break
> their guarantee. But that's orthogonal to my original point.
>
>> And now
>> some people work on using BrandZ (if you know nothing about it, it's
>> sort of like our technology used to do our linuxulator or freebsd32 on
>> amd64; that's not accurate, but is good enough for the point I want to
>> make) to provide a Solaris 10 container (think about it as a jail on
>> steroides) with an Solaris X (X < 10) image, so that people can install
>> a Solaris 10 host and run Solaris X in it (like our linuxulator in a
>> jail, but not as flexible as our linuxulator, theirs can not run on the
>> main system like ours can).
>
> Right, having the linuxulator in the kernel is all but
> unavoidable. But for old FreeBSD apps running on newer versions of
> FreeBSD, we can do better, and a library-based approach is easier
> to maintain and less prone to security problems.

It's not running only old apps on a new system, it's running the =20
userland of an old system in a jail of a new system. That's what I'm =20
concerned about (and works currently as we took care about maintaining =20
compatibility in the kernel) and that's what you can not handle with a =20
library-based approach.

Bye,
Alexander.

--=20
You get what you pay for.
=09=09-- Gabriel Biel

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID =3D 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071211080216.pb3b95teoggko00o>