From nobody Sun Sep 08 11:59:26 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 4X1pS136z4z5TdDX for ; Sun, 08 Sep 2024 12:00:01 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1pS03C6Tz4xtL for ; Sun, 8 Sep 2024 12:00:00 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=G1a0blsm; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1725796792; 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=VTxi0MnOL4Y5oWEnGjumv+4M346cxK04eI371VI1oQY=; b=G1a0blsmLnv4wOUT1jvr3AIVhHjFdzNfCWdmfsgAdaEoW41izzBN10VK0M+OOrLhg7YLGS YaHMlxnzK69zCTIP1sG0PRQmpncPjJqSF7qnlvF9k/Gq3QBYx+XGDt0BSbJSkTZd93c/ud XHvTpz8meniT2utvbNN9qn7J+jj8tdBXE7sTI+TyejgsG5iTknZe5bnFe8l+sBSJ1VAJc8 OUcoo47PrY9DDRSmtJeyVSww2GvZ50RXTn1Oy0dPhlYtbtKTh1jj2woM4ZKkP56D+ExiBo si80L7XM8HP9TWo/+cp9FJppQS/91WpHz7bfp+g+dGMMy7i9RpGt4Yhx3RDYRQ== Date: Sun, 08 Sep 2024 13:59:26 +0200 From: Alexander Leidinger To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> Message-ID: <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_46065de06a756b4ed727ec5ac4d511ed"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4X1pS03C6Tz4xtL This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_46065de06a756b4ed727ec5ac4d511ed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-09-03 17:32, schrieb Poul-Henning Kamp: > What is FreeBSD ? > ----------------- > > Forget Rust for the moment, I promise I will come back to it. > > FreeBSD as a project was created almost entirely as protest against > the incompetent "UNIX-industry" as it existed around 1990. > > One of the stupidities we reacted against, was the unbundling of > the C-compiler: If you bought a UNIX system, the C-compiler would > cost you extra, even through everybody knew that the vendor got it > as part of their source license from AT&T. > > So from the very start, FreeBSD decided to deliver "A complete UNIX > system with full source" and the only concession was that, hard > disks costing what they did, you could choose to not install the > manual pages and the source code on systems which did not need them. We are waaaay past that. The world is not only ftp and smtp servers anymore. > The source tree became our citadel: "FreeBSD is src". If something > was not in src, it was not FreeBSD. We are way past that too, FreeBSD is src+ports+docs(+community). [...] > But a FreeBSD system recompiling itself from source is even rarer. In your world. And in the world of some other people. But there are a lot of worlds where this is not true. I have systems which are updated from src, and use only packages which are build locally. > And when it does, LLVM, source code we import verbatim from an > entirely different project, and which no sane person would call > "Related to FreeBSD", takes up more than three quarters of the > compile time. > > That is objectively absurd. > > The only reason we do that, is because we stil have that outdated > "FreeBSD is src" emotional hangup. I don't think so. I'm sure everyone agrees that FreeBSD is not only src. You already told it yourself. It's src+ports+pkg + other add-ons which all live in the FreeBSD ecosystem. > We need to find a contemporary and useful answer to "What is FreeBSD?" > > The only answer I can think of > ------------------------------ > > "FreeBSD is ports (some of those ports contain the kernel and > userland)" I propose "FreeBSD is packages" (and at the same time it isn't, but all of the before mentioned stuff). How those packages are generated doesn't matter, this is an implementation detail. "make buildworld" can create packages. "make installworld" can install those packages. "make distribpkg" can copy the basepackages to a directory structure similar to what poudriere does which would allow to use "make whatever" in src and poudriere to generate a package set for your site, your product, or only yourself if you want to. It also would allow to continue using finger memory, and have those which which to do so update the stuff via the old way instead of using pkg (while having it installed via pkg in the background). > As part of the migration, we yank LLVM out of the src. Together with the possibility to use an external toolchain, this is possible. I would welcome it to have a "freebsd-15-llvm-YYYYMMDDnn" port which can be build on all supported releases and contains a compiler which is able to compile FreeBSD-15 instead of llvm in src. Ideally this tollchain port doesn't contain much local patches, so that I could grab the source of it on OSX or Linux and use it to build FreeBSD (well... I wouldn't, so far I've build FreeBSD only on FreeBSD, but we have committers which use this, so we should keep that in mind when we create such a port). This external toolchain support should be generic (and I cross fingers that Shawn has the time to come up with something sensible / extensible). In that case the discussion about which language to use doesn't matter anymore. It would allow up the possibility to have the non-optional stuff managed in src, and optional stuff managed in ports. It would allow to play around with different languages and to provide replacements in different languages in parallel. This means that any alternative is able to prove itself. Without the bikesheeding of theoretical stuff, but by presenting evidence. > LLVM does not belong in src by any sane criteria, and any microscopic > benefits of "tight integration" can be delivered with a > "toolchain-llvm" > (meta-)port. > > Our minimal install images will contain: > > The installer > The kernel package(s) > The userland package(s) An implementation detail which only matters once we have the possibility to chose from packages... > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. I still think "make installworld" should be able to update my system (and I should not care if this is done by using pkg or not, e.g. by pointing pkg to the buildworld-generated packages repo in OBJDIR). A more generic out of the box view than what PHK started follows now, not directed at PHK directly but to all of us: I do not think this is all what is needed. This proposal is surely a step into the (IMO) right direction, but we should also discuss where we stand with what we have already and where we should go with that. flua is there, but there is no integration of what we have (recently there started a discussion to add some freebsd modules to make freebsd basesystem stuff accessible from flua, which seems to go into a (IMO) good direction). Similar for C++. We have some C++ code in the tree, but we have no guide for it. Not only in terms of extensions to our style-guide, but also in terms of what we want to see in terms of good practices. C++ is complex, had a lot of changes since I first seen it in 1999. IMO we should use the most recent C++ standard which our oldest supported release is able to compile (to be reviewed every time a release is EoL resp. with every major update of the external toolchain for the oldest release we support). And we should provide some guidelines of what we want to see in our C++ code (as a very basic example: use smart pointers instead of raw pointers, or X instead of Y). Some of this may be common knowledge, or best practices, but IMO we should have a document of what we want to see. We don't have that for C either, but I think we should have that for C too. We want to attract new people, and something like that would make it more easy for new people to join. Similar for our kernel interfaces. We have several of them, but we have no document which explains which kind of interface to use for which kind of stuff. And we have multiple ways to do something in the kernel, some of them old stuff replaced by new stuff in some places but not all places, and a document which talks about those parts (e.g. new code should use X instead of Y, or if you touch it, please also do a migration to Y at the same time). I bring this up here, because this is part of our code debt (and there is surely other stuff which should be included too). And every discussion about C vs C++ vs language of the day is implicitly a discussion about code debt. All the arguments about we don't need more than C are valid. At the same time all the arguments about the need for are valid too. In the end it's about code debt, about cognitive load, code quality assurance and so on, not about the language itself. While we gain experience, we all don't get younger, may have not slept well last night, may have a hangover, medical issues, have a broken heart, or be distracted. Anything which makes it more easy to produce a good result is important, and as a project we don't have the luxury to be able to say "we always did it like this". We are proud to provide possibilities, but not policies on our OS. We should be open minded enough because of that to provide the possibility to let people use any language, not only in userland, but also the kernel. If someone comes up with a subset of C++ to be used in the kernel, why not? If this needs a bit of support in src, why not? The same for rust or any other language. We need to draw a sane line somewhere, sure, but we should not blindly say no to it. Someone wants to prove that language X is a good addition to the kernel and it needs 2k lines (an arbitrary number I just picked out of thin air, don't nail me down on this number) of changes to make it possible which can not be done as a module and does not come with a too big cost, why not (mark it experimental, make it an option, ...)? In the end any touring complete language with enough low level possibilities is suitable to write an OS, and if the language of day is suitable or not, can be seen by letting it proof itself in this regard. If it isn't suitable, no important new stuff will be produced and it will vanish. If it is suitable to an extend never imagined, it will take over the world and old stuff is replaced. Time will tell, but nothing bad will happen if we allow the possibility to give it a try and make it even easy to give it a try. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_46065de06a756b4ed727ec5ac4d511ed Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbdka0ACgkQEg2wmwP4 2IZvcg/+LCa2e41ksgRPF0Wdx2G+1qJtDwXnMr1x9/KTo2hvHkW+mwyntaKNoH9Z UE/7rszPDmjTaHLS+KFUgfZooSQQY+YtGM/SAbt2XAqYuMOu6llYAolMVFEWl6J1 RsWZt8rIRW7AWzbXABE2+VLpLKgmK0nq68XKbbqeYxVPyFP7TUvotNC3K3opiiVj pvV5lPxXWkhUocWOsq0ot3TVPnraIyAmPtmdsysbWATo+m3eYHDH/dvktFY+D+Ez HVa2NM6BSU4UUUW0YlhPkMZ3biqAgrOu7NHOuhFJzUCX+FDoCtnkZg37nn4Ka0XM N8x9Xo7825rF7+OXHxexoCZubOfj+8hzkNfJw6VoOXC04TSXIoX5o3mEIL6eGkgI 7BiBM0Uk2XFxkXKJCEuQspbUBYKV0aHjtDt/3rGUzl1IYqFj0kUCh46P1sCmh5qn irAlFYJOhlL4Ii/t3QNniepRyufdMo1FPhoIIQefDf0/VvyCTpJEsF4LyQDr1YT3 1MsykPlA/xt349Bkt4wP4KtjAL76zBEJVQAwAaWepEaO7SZxxBcy743FqsKFHaox 4I2Nfa/Igt26HMSNmJNiG4ntcJSNSogKDkO26NmwR4gXbPWsL8S83uu89McZaXni 6eSGW7cyrLOZZeZYd86JKTCxL6YWEQvipHnH/Z1xuXCdMrTF/Po= =Xooi -----END PGP SIGNATURE----- --=_46065de06a756b4ed727ec5ac4d511ed--