Date: Wed, 23 Aug 2023 08:42:54 +0200 From: Mario Marietto <marietto2008@gmail.com> To: ports <ports@freebsd.org>, emulation@freebsd.org Subject: Re: Building a Linuxulator userland from source Message-ID: <CA%2B1FSijH2XxAS5O0F3h7jxhGFs048TYD6zqwByyE-Wcxq_zftw@mail.gmail.com> In-Reply-To: <fawky2wibrfhepv35e7zatnqgdkqjjmwbe7vsldqsbdmomyrnk@dj7fzyh2ufgd> References: <xcztahm3vu3bjghjqqxuoy2xabyjmyfq22jw6mkaaaqo7wa36s@fdq7dlvpuhlk> <20230822173454.458DB237@slippy.cwsent.com> <fawky2wibrfhepv35e7zatnqgdkqjjmwbe7vsldqsbdmomyrnk@dj7fzyh2ufgd>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000901dd30603916c50
Content-Type: text/plain; charset="UTF-8"
It would be nice to try that tool that can hack / convert ./ add another
layer (another linux distro inside the first one. I dont remember the name
now.
Il mer 23 ago 2023, 08:21 Felix Palmen <zirias@freebsd.org> ha scritto:
> * Cy Schubert <Cy.Schubert@cschubert.com> [20230822 10:34]:
> > Basically this would become another Linux distro, albeit a virtual one
> > that runs under our Linuxulator.
>
> And also a pretty minimal one. Right now, I'm just building a truly
> minimal userland (the GNU toolchain, openssl, GNU make/grep/sed/awk, GNU
> coreutils and man-db) and working on putting together some sane USES for
> that.
>
> > Avoiding discussion about packaging -- we can package this any way we
> > wish -- how will this support software written for distro A, B, or C.
> > For example, Red Hat software doesn't neccesarily run on SuSE or
> > Ubuntu because shared library dependencies may be different.
> >
> > Building our own "distro" to run under the Linuxulator may require a
> > complete set of packages and end-user applications because existing
> > Linux software may require a Fedora, Debian or Red Hat library.
> > Wouldn't this negate the need for a Linuxulator because a person can
> > build most Linux software to run on native FreeBSD.
>
> Well first, when I ask why "Linuxulator" is needed, the answer in my
> head is: Mostly for closed-source Linux software. Because exactly as you
> say, anything else should better be ported and built to run natively on
> FreeBSD, if possible.
>
> Now, maybe I'm looking at the wrong software? In my experience with
> closed-source Linux Software, sure, it *might* offer
> distribution-specific packages, but almost always offers a plain binary
> tarball as well. The latter could easily be used to create a port (like
> was done in the past as well in our tree), and then it's just a question
> of adding ports for the (hopefully few) shared libraries needed by this
> software.
>
> > I think a better path might be to support multiple Linux userlands in
> > parallel. Thus a user could simply copy or install vendor software for
> > a Red Hat in one environment and a SuSE vendor software in another.
>
> This would be the consequence if you really want to support
> distribution-specific software packages. I don't think it's feasible in
> practice, at least it would make it very hard to still have ports of
> Linux software (like my makemkv port), these would need to build and run
> with any of these userlands.
>
> To challenge my source-based approach, I'm looking for "proof of
> concept" closed-source software to try get running with it, I'll
> probably start with makemkv because I already maintain that port. Open
> to suggestions what else to test there. In the end, getting to run e.g.
> Google Chrome would be perfect, but I imagine this requires creating a
> lot of ports for shared libs first.
>
> Cheers, Felix
>
> --
> Felix Palmen <zirias@FreeBSD.org> {private} felix@palmen-it.de
> -- ports committer -- {web} http://palmen-it.de
> {pgp public key} http://palmen-it.de/pub.txt
> {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
>
--000000000000901dd30603916c50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">It would be nice to try that tool that can hack / convert=
./ add another layer (another linux distro inside the first one. I dont re=
member the name now.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">Il mer 23 ago 2023, 08:21 Felix Palmen <<a href=3D"m=
ailto:zirias@freebsd.org">zirias@freebsd.org</a>> ha scritto:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">* Cy Schubert <<a href=3D"mailto:Cy.Schube=
rt@cschubert.com" target=3D"_blank" rel=3D"noreferrer">Cy.Schubert@cschuber=
t.com</a>> [20230822 10:34]:<br>
> Basically this would become another Linux distro, albeit a virtual one=
<br>
> that runs under our Linuxulator.<br>
<br>
And also a pretty minimal one. Right now, I'm just building a truly<br>
minimal userland (the GNU toolchain, openssl, GNU make/grep/sed/awk, GNU<br=
>
coreutils and man-db) and working on putting together some sane USES for<br=
>
that.<br>
<br>
> Avoiding discussion about packaging -- we can package this any way we<=
br>
> wish -- how will this support software written for distro A, B, or C.<=
br>
> For example, Red Hat software doesn't neccesarily run on SuSE or<b=
r>
> Ubuntu because shared library dependencies may be different.<br>
> <br>
> Building our own "distro" to run under the Linuxulator may r=
equire a<br>
> complete set of packages and end-user applications because existing<br=
>
> Linux software may require a Fedora, Debian or Red Hat library.<br>
> Wouldn't this negate the need for a Linuxulator because a person c=
an<br>
> build most Linux software to run on native FreeBSD.<br>
<br>
Well first, when I ask why "Linuxulator" is needed, the answer in=
my<br>
head is: Mostly for closed-source Linux software. Because exactly as you<br=
>
say, anything else should better be ported and built to run natively on<br>
FreeBSD, if possible.<br>
<br>
Now, maybe I'm looking at the wrong software? In my experience with<br>
closed-source Linux Software, sure, it *might* offer<br>
distribution-specific packages, but almost always offers a plain binary<br>
tarball as well. The latter could easily be used to create a port (like<br>
was done in the past as well in our tree), and then it's just a questio=
n<br>
of adding ports for the (hopefully few) shared libraries needed by this<br>
software.<br>
<br>
> I think a better path might be to support multiple Linux userlands in<=
br>
> parallel. Thus a user could simply copy or install vendor software for=
<br>
> a Red Hat in one environment and a SuSE vendor software in another.<br=
>
<br>
This would be the consequence if you really want to support<br>
distribution-specific software packages. I don't think it's feasibl=
e in<br>
practice, at least it would make it very hard to still have ports of<br>
Linux software (like my makemkv port), these would need to build and run<br=
>
with any of these userlands.<br>
<br>
To challenge my source-based approach, I'm looking for "proof of<b=
r>
concept" closed-source software to try get running with it, I'll<b=
r>
probably start with makemkv because I already maintain that port. Open<br>
to suggestions what else to test there. In the end, getting to run e.g.<br>
Google Chrome would be perfect, but I imagine this requires creating a<br>
lot of ports for shared libs first.<br>
<br>
Cheers, Felix<br>
<br>
-- <br>
=C2=A0Felix Palmen <zirias@FreeBSD.org>=C2=A0 =C2=A0 =C2=A0{private}=
=C2=A0 =C2=A0<a href=3D"mailto:felix@palmen-it.de" target=3D"_blank" rel=3D=
"noreferrer">felix@palmen-it.de</a><br>
=C2=A0-- ports committer --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0{web}=C2=A0 <a href=3D"http://palmen-it.de" rel=
=3D"noreferrer noreferrer" target=3D"_blank">http://palmen-it.de</a><br>;
=C2=A0{pgp public key}=C2=A0 <a href=3D"http://palmen-it.de/pub.txt" rel=3D=
"noreferrer noreferrer" target=3D"_blank">http://palmen-it.de/pub.txt</a><b=
r>
=C2=A0{pgp fingerprint} 6936 13D5 5BBF 4837 B212=C2=A0 3ACC 54AD E006 9879 =
F231<br>
</blockquote></div>
--000000000000901dd30603916c50--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSijH2XxAS5O0F3h7jxhGFs048TYD6zqwByyE-Wcxq_zftw>