Date: Tue, 10 Sep 2024 11:05:38 +0200 From: Olivier Certner <olce@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: <2372745.viN5riZIyJ@ravel> In-Reply-To: <202409091859.489Ixdia086264@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> <202409091859.489Ixdia086264@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2111829.mIT35NG9lc
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: freebsd-hackers@freebsd.org
Subject: Re: It's not Rust, it's FreeBSD (and LLVM)
Date: Tue, 10 Sep 2024 11:05:38 +0200
Message-ID: <2372745.viN5riZIyJ@ravel>
In-Reply-To: <202409091859.489Ixdia086264@critter.freebsd.dk>
MIME-Version: 1.0
>> - A system that is easy to build and tweak in practice (for developers a=
t the very least).
> But what are the boundaries of this "system" of which you talk ?
In the quote to which you responded, "system" simply designates FreeBSD, or=
the "base system" to be even more explicit.
I have not accurately described what this "system" should include, simply b=
ecause I don't believe it can be delimited precisely ex abrupto in all gene=
rality, as this depends on a lot of factors (amount of people; what they ar=
e willing and able to work on; which upstreams project exist, can be used, =
and are cooperative; technology evolutions; our collective project directio=
n; etc.).
That's why I gave some high-level view of what I think the project is and s=
hould remain, and without which its nature would be considerably altered (I=
'd really like to hear other's points of view). And I contend that this vi=
ew is more important than the precise detail of whether we have this or tha=
t as "base".
However, according to that view, I'm more or less coming to the conclusion =
that FreeBSD should include the compiler. Which doesn't mean its code has =
to *live* in the 'src' git repository, nor does it mean we cannot rebuild F=
reeBSD without using pre-packaged binary or an earlier build from source.
Before elaborating further, I'd like to expand a bit on my earlier list of =
what FreeBSD is/should be. I had written this, in particular:
> - A system that is self-sufficient, in the sense that, once installed on =
a machine, one can set it up to do whatever one would like without having t=
o boot something else (e.g., further software installations must be possibl=
e over the network or from some USB key; so it must include some tools to s=
upport the network, etc.).
> - A system that is easy to build and tweak in practice (for developers at=
the very least).
I would add that "self-sufficient" also means that it can be easily built e=
ntirely from source from itself and other commonly available systems. And =
also, as developed at the end of my previous mail, that it is easy to obtai=
n a workable view of all the source.
=20
> I am more or less responsible for nearly two hundred computers
> running FreeBSD right now. Only two of those have zero ports/packages
> installed, one monitors my floor heating system, the other firewalls
> some old crap.
>=20
> To me "src+kernel" is just the foundations.
>=20
> "A system" is what people build on top of the foundations.
That's one possible view of a system, which is consumer-oriented rather tha=
n developer or software-project-oriented. And I could return the question =
to you: What's the limit of your "system"? One computer? Your network? A gr=
oup of machines owned by someone? Or accomplishing some special task? Does =
it include the network (routers, cables, etc.)? Does it include your ISP? =
These different groupings can always be seen as foundations of other, bigge=
r ones. Without more context, I don't see how this foundation/system disti=
nction is going to be fruitful.
By "system", or FreeBSD base, I mean code written, overseen and/or managed =
by the people comprising the FreeBSD project, with the goals listed in my p=
revious mail. I think that's the fundamental difference with ports: Ports =
are... ports of software developed externally (which doesn't prevent some p=
orters to contribute to upstream), not necessarily tied to FreeBSD's code, =
not having the same quality insurance, nor the same coding policies or rele=
ase schedules, and not collectively maintained by members of the project (a=
t least, we do not promise that; of course, members are individually free t=
o participate to whatever upstream project they like).
There is no denying that for lots of (most?) tasks, being able to run these=
ports is a pre-requisite, it's just that we are not responsible for their =
development. What porters are responsible for is ensuring that we can buil=
d and run these softwares on top of FreeBSD, with varying degrees of qualit=
y (depending on the size of upstream, the number of porters for each projec=
t, their level of engagement, etc.). This sometimes entails participating =
to upstream development, but does not require setting, e.g., the full archi=
tecture or roadmap of these projects.
So, while we as a group are not living in an isolated island for sure, and,=
e.g., should strive to maintain good working relationship with other proje=
cts, we are not (and cannot) be the developers or maintainers of all useful=
software. But we have to be so for software that we consider part of Free=
BSD.
Of course, code that is our own (provided, again, that it is needed to fulf=
ill the high-level principles), i.e., for which there's no upstream and no =
changes happen that aren't done or fully reviewed by project members (well,=
this may be slightly idealistic, but hey...), belongs to 'src'.
=46inally, we have the kind of middle-ground comprising upstream projects, =
such as LLVM, which AFAICT are growing in number. As long as we consider t=
hem to be needed in FreeBSD ("base") according to the high-level principles=
, we are responsible for them functioning correctly and consistently with t=
he rest of the system, even if we are not the primary developers. So, we a=
lso "own" this code, albeit differently to code entirely in our hands. And=
it should be maintained collectively. From commits and internal discussio=
ns, I can identify more or less correctly the (small) group of FreeBSD peop=
le working on LLVM in FreeBSD. If, for some reason, these people would sto=
p working on it, we would have a problem, to which I expect the project as =
a whole would respond with actively trying to find a solution (some would i=
nvest more time to work on it, and/or we would try to find external people =
who can, or we would switch to another toolchain, etc.). If, for some reas=
on, let's say, Firefox would lose enough of its developers to have its viab=
ility threatened, I don't expect us (as a project) to react to that as Fire=
fox is not part of base. This doesn't exclude having a project response to=
the difficulty of *porting* some software that we deem very important for =
the ecosystem, occasionally or in a longer term fashion.
This is only my view, but I have the feeling it is implicitly shared by man=
y. I'm very interested in hearing whether it is more or less conform to re=
ality and what people think about it as of now and for FreeBSD's future.
That said, I also think this debate is mostly independent from the possibil=
ity of building FreeBSD without having to rebuild a full compiler every tim=
e. It is however relevant to the proposal of removing LLVM's code from 'sr=
c', as this has bad consequences (according to the principles I listed) tha=
t we probably can, and should, remedy with tooling, although, as the saying=
goes, the daemon is in the details.
Thanks and regards.
=2D-=20
Olivier Certner
--nextPart2111829.mIT35NG9lc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmbgC+IACgkQjKEwQJce
Jiekqg//Qkpz81a9uLWWWXPPpwJ355VlZFitQ9Cz0OvY0qf3oOVjfsy1sgzW/S81
s8pUk2nDUHw/mPhLsNgp7NjI9NzDMs1m66IWJgfI/tzsfkoVflN6uJ5zrDCLdMKy
NsT2h0fpzkZn4JGBksb9wsq84S3yaOTLcvGQlYj/c81pogHklYXbmdDX+5emYh8e
SuhrV/9ANViKAIbYlg4KRmyL9ocWK2/I6i30otlrvZq8AxoqUDDJj2fKvYv/b6fR
k8HYAYIninxIzYjod31H/vxAWcfIfU3FvVdj/ZE9ZNKApAAysi4lYRaVpRSmUyWT
gVVJIVujseW7PvimJQc0+/X78JQwWWE+yOymIu/bVF8j/DUwBMDCzL5BcsbOFtxk
/V9JKcgeDJSEmxBOx1x0mzn2YKtO+qU3gE3MtSu6RS8rZ5HtJP7Ap+GJVdKrs6f4
huy3gZLN5EHOR4PbSNiPhljwash3A8gRfZjw7SvXcBbHA1clVUAjgS8YgpNgifem
EezJM0odNmpZchUlbJM7kzGtZo16XlujZWfgVlZOdbiwU4IUgGgkJKZgSgsNFflV
ksicOndvgh2v4OP3xlxDXVvfD8+5JhWbiwl42OLTrflMRgkibZnGAMezz983HKWO
ibBVoxM3rq5GEsX1jNNQYqjSJ8ZH36gLT/5RvxoFLtSiW+8gvuI=
=OPAQ
-----END PGP SIGNATURE-----
--nextPart2111829.mIT35NG9lc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2372745.viN5riZIyJ>