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
[-- Attachment #1 --]
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
>
[-- Attachment #2 --]
<div dir="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 remember the name now.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il mer 23 ago 2023, 08:21 Felix Palmen <<a href="mailto:zirias@freebsd.org">zirias@freebsd.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Cy Schubert <<a href="mailto:Cy.Schubert@cschubert.com" target="_blank" rel="noreferrer">Cy.Schubert@cschubert.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<br>
> Ubuntu because shared library dependencies may be different.<br>
> <br>
> Building our own "distro" to run under the Linuxulator may require 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 can<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 question<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 feasible 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<br>
concept" closed-source software to try get running with it, I'll<br>
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>
Felix Palmen <zirias@FreeBSD.org> {private} <a href="mailto:felix@palmen-it.de" target="_blank" rel="noreferrer">felix@palmen-it.de</a><br>
-- ports committer -- {web} <a href="http://palmen-it.de" rel="noreferrer noreferrer" target="_blank">http://palmen-it.de</a><br>;
{pgp public key} <a href="http://palmen-it.de/pub.txt" rel="noreferrer noreferrer" target="_blank">http://palmen-it.de/pub.txt</a><br>;
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231<br>
</blockquote></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSijH2XxAS5O0F3h7jxhGFs048TYD6zqwByyE-Wcxq_zftw>