From nobody Tue Sep 10 09:05:38 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X2yV21hH7z5V7q0 for ; Tue, 10 Sep 2024 09:05:46 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2yV20zGyz4T4W; Tue, 10 Sep 2024 09:05:46 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725959146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D2fSB6WOxSCJwL2KZHlylk2zqtoua9RCPuHiZm1hUB8=; b=KGr0sTkdDcAzWMM639BQj79s1UVx4IeKdExsjkHDfaZ9vNPNeQ/9rQt8QHK3t0bQJXn97l Uq/EVvb5DUo2gqpauSRJGHfSn12LXm9iMHzZEk1TRiqKtk5VWgIS3clzgJ+NIkHIYXxaSZ xqBUvn/bpHYPyC4rgSNz5cyawFLthnGi0KuYs5HA/jWD27MdB5MfrJ3y2li+csJgDf9VmC GaOS83Y8F46w9p4j4tcdAVhFnEQcHmGYGM6eLti83P9uShNdX4lwaPFY0s3FTDqcaOH19K vBpBzonZy/uXFNFsJuuc7dv9koVzAy2zgkww/MPpQgv0cDTfNcERZhLSAIjzVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725959146; a=rsa-sha256; cv=none; b=lG8u4vu/EVMITcVVO4Pnfyvia0pegZMNgMLldu7i+71R+wl3OLR7LjkpfN9kG+4IoVS14J j+iYguwT2mnNvSy2OYO5kxhKpmF4FQuFxg+WhLApmbJMERA5w4pQ9/wEgY8sM/15DTFw56 T3FfjonT+fpG5d3QMBKbx7ihve2edPlk5bj8WFS2BtAMXhvGc1Dou46cch9i27pGjtD0vf iYJfVQuxQ3YM5apNN1HQSKgJ3vG7QMuLIbP4iwFA4zZv9KS4se3hMbTy7WAVyzQL2J0gPc WQ8Vmahqi9vT9fDC/HllGuRPpUjTC+KaY851PHeRwEASr2737wfzazKFiPjIuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725959146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D2fSB6WOxSCJwL2KZHlylk2zqtoua9RCPuHiZm1hUB8=; b=vk1hdsersdGqEXOreMrw01bD1Mu18mVZlILEZQ9KaKPxEAsDf0tMEEdlwq1yLtVOA96Gyu lTSEHs/YL1sPrTE9uDhTITWfb2ESl+3JkVSJCPGOeSzN3Y5xqyuA+ki6A/GXr4TgYHc5xf P9UMF9K7u2WKjir5lYZsV/KkTN0hAbcONrTUHXQ9SZR363ifiNTkxOgvBKeX9UQVYyai7v foF2WUKv3T5deoXWzoF6i7pF2Mw+2RKAHCZ04B0W58raxF8Pg5sQ523ZCQ4f0M2DQnLeqN mv+tyF7raSJxl2gpM4LMCxCPef1G8pdSZ4M7kgNtlPYeBxo3xRyZNNFJ73Hk0w== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2yV14hrKzM1C; Tue, 10 Sep 2024 09:05:45 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Poul-Henning Kamp 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> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> <202409091859.489Ixdia086264@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2111829.mIT35NG9lc"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2111829.mIT35NG9lc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Poul-Henning Kamp 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--