From nobody Mon Sep 2 22:23:57 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 4WyNb10FXRz5V8pJ for ; Mon, 02 Sep 2024 22:24:13 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyNb02vrtz4Tmg for ; Mon, 2 Sep 2024 22:24:12 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=QmsTYTBz; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::1135) smtp.mailfrom=tomek@cedro.info Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6d5893cd721so21229967b3.0 for ; Mon, 02 Sep 2024 15:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725315851; x=1725920651; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=os8aEGW1aud0LHaMtTXv5bryjoyspGkNuJ6pbQquXWs=; b=QmsTYTBzLGm5y1blJ31RmK9OYjiJwdyTRtkW/7DtX7CKkZM9aw5ZokcFnShXEaHqB4 FS/dv9iIF4bICsiSTrJNP5GErWuUrLx5PXSXyUHvKp+jSpl2yP5FFnE/MFoDCPtl6Qnz qflVX9vjdFJrfNxI05+g40L8jaJNSYynpP45RO0UJ1WSeBr6q/j7eIDsy+eIyp3oZw4g RC/XJ2XP3BmwEOWBegbZz+0iUK5PEG0B++SpjUm2v/pyj30pCRXIc0DehawmkwpRu4Eg 1VrGqfJ6cmjsU5iFWx4Khi+Kq0WW4WTJutJqFE3AhKnxrpGg/YIkpBUU5pF8w9JR+0TC xClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725315851; x=1725920651; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=os8aEGW1aud0LHaMtTXv5bryjoyspGkNuJ6pbQquXWs=; b=SbDYxNvTO0y8hXsyb8yROVgD1OCANmOAkWq73hH36U4Psz66lycs2YZ2umsEzM+fM+ wG9nIwjRdu5tEJvcAtq73L10xsszt/cjIIlekP8tHEkDqxhgVjxiMrN2tOGmzYgywHFs gNw5HrP6VpzRwKUqVtroSkVnO4Baw8155/0tUHTl126gr9DHCMnofn98TO1WU/PHbW8Q 6SBx8I0P3X3gTKk3NBQHQ/SlVav6CAm9pIKr3YxB63SDG6BPypw5zTHx06lPqNmJ6UKr qKx33SOiwTIuULxSRXVJfLYCpVcRICybGPdl1Ojvv++41C4rGA+ucpPLUu3LhNPtGx2J fWSg== X-Gm-Message-State: AOJu0Yz+eo3uA3Y/oquWLkDChaA5qOBGSFxEx2nh/qSSsvRgyDTifG0G G4T2t3D6KWkX0rM+5Iwu95IOCE+8cbdNMaSqv30bbUbE0CFZZwM6H3WLiRw6uMi2VmU/ZUX+I8k = X-Google-Smtp-Source: AGHT+IFZr0JZ6U455BweSkwkQONzJF4ARgLzT+xcOvd7buqtubZk30u+T4Gv04dBnLjq1LAWLUfQnw== X-Received: by 2002:a05:690c:660b:b0:6d3:d842:5733 with SMTP id 00721157ae682-6d40f927a23mr132159507b3.35.1725315850990; Mon, 02 Sep 2024 15:24:10 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6d67a541150sm7172687b3.115.2024.09.02.15.24.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Sep 2024 15:24:10 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e1a9dc3efc1so2304612276.2; Mon, 02 Sep 2024 15:24:10 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU+bJH1pJN34coX5+0Wf/y8uFsawwhKoQFSLYT67P+S9e0OP8CQiHvHdZbZmmOLwKEuayofJ1+R@freebsd.org X-Received: by 2002:a05:690c:4e0c:b0:672:8ad4:9461 with SMTP id 00721157ae682-6d41000902bmr99123697b3.41.1725315849786; Mon, 02 Sep 2024 15:24:09 -0700 (PDT) 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 References: In-Reply-To: From: Tomek CEDRO Date: Tue, 3 Sep 2024 00:23:57 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: The Case for Rust (in the base system) To: FreeBSD Hackers Cc: Warner Losh , Alan Somers , Konstantin Belousov Content-Type: multipart/alternative; boundary="0000000000005a261506212a66c9" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from,209.85.219.172:received]; DMARC_NA(0.00)[cedro.info]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[bsdimp.com,freebsd.org,gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4WyNb02vrtz4Tmg --0000000000005a261506212a66c9 Content-Type: text/plain; charset="UTF-8" Rust for Linux maintainer steps down in frustration with 'nontechnical nonsense'. Community seems to C Rust more as a burden than a benefit https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --0000000000005a261506212a66c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rust for Linux mainta= iner steps down in frustration with 'nontechnical nonsense'.
<= div dir=3D"auto">
Community seems to C Rust more= as a burden than a benefit

--0000000000005a261506212a66c9-- From nobody Mon Sep 2 22:30:23 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 4WyNkD2w41z5V9QN for ; Mon, 02 Sep 2024 22:30:28 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyNkC6fSwz4Vxm for ; Mon, 2 Sep 2024 22:30:27 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725316226; x=1725575426; bh=Tbgr33/XbQgKJM8WuAx1dYKLEvnHFQ9+Kyh1QDDOIVM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=OZfhmCBU0JlfeR+I5YB+9zFVT3xH4T5O/GHQ2PV3djiyM6Ng7A3KzTTkgDKNBt9rx S2oMEjlmcFrm2d80f3hTEjEoGwA+wKPd8/3CFpZ6G2gQEsBZut84XKFGX+WQbmDAwt kR+B0S2wRkY1avnGZ5RR15OPzDJ7ah6ArBc6/WxtWuib0BYUU+SCPscLQ7OMVJsplE O0EqbWk1N5O3Tf/kvKDhq1XNG/fPDiJDzWpQQGGMuTILOuBRvD20LvhZpcZ+vibPqA N/Q5q4918lJrfXGQ+HtCe/30IKnSEgvS6vdZhU6QVY65yfOQ7nl0GobOoGSL4W8VSd aV5TsJSqjl1kA== Date: Mon, 02 Sep 2024 22:30:23 +0000 To: "tomek@cedro.info" , "freebsd-hackers@freebsd.org" From: fvalasiad Cc: "imp@bsdimp.com" , "asomers@freebsd.org" , Konstantin Belousov Subject: Re: The Case for Rust (in the base system) Message-ID: In-Reply-To: References: Feedback-ID: 78761413:user:proton X-Pm-Message-ID: af7aa3912ba2c9c4c6c50dd5e089d123b9e5faad 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/alternative; boundary="b1_iTH0PCNopWNcyRHovrIxxPkmmXyFEsRuJS5y71D64" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4WyNkC6fSwz4Vxm This is a multi-part message in MIME format. --b1_iTH0PCNopWNcyRHovrIxxPkmmXyFEsRuJS5y71D64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UnVzdCdzIHBvb3IgZWNvc3lzdGVtIGFuZCBsYWNrIG9mIGEgc3RhbmRhcmQgbGlicmFyeSBkb2Vz bid0IHJlYWxseSBoZWxwLgoKSXRzIGZhbnMgYXJlIGFsc28gYSBsb3VkIG1pbm9yaXR5LiBUaGUg c29vbmVyIHBlb3BsZSBzdGFydCBsb29raW5nIGF0IGl0IHRoZSBwcm9wZXIgd2F5LCBhcyBhIHRv b2wsIGJyaWdodGVyIGRheXMgZm9yIExpbnV4IHdpbGwgY29tZS4gSG9wZWZ1bGx5IHRoZSB0aW1l IHdpbGwgY29tZSBmb3IgdGhhdC4KCkZvciB0aGUgdGltZSBiZWluZywgaXQgdHJ1bHkgaXMgYSBi dXJkZW4gdGhvdWdoISBJJ2QgY2FsbCBpdCBhbiBpbnZlc3RtZW50LCBwYXRpZW5jZSBwZW9wbGUh CgotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tCk9uIDkvMy8yNCAwMToyMywgVG9t ZWsgQ0VEUk8gIHdyb3RlOgoKPiBSdXN0IGZvciBMaW51eCBtYWludGFpbmVyIHN0ZXBzIGRvd24g aW4gZnJ1c3RyYXRpb24gd2l0aCAnbm9udGVjaG5pY2FsIG5vbnNlbnNlJy4KPgo+IENvbW11bml0 eSBzZWVtcyB0byBDIFJ1c3QgbW9yZSBhcyBhIGJ1cmRlbiB0aGFuIGEgYmVuZWZpdAo+Cj4gaHR0 cHM6Ly93d3cudGhlcmVnaXN0ZXIuY29tLzIwMjQvMDkvMDIvcnVzdF9mb3JfbGludXhfbWFpbnRh aW5lcl9zdGVwc19kb3duLwo+Cj4gLS0KPiBDZURlUk9NLCBTUTdNSFosIGh0dHA6Ly93d3cudG9t ZWsuY2Vkcm8uaW5mbw== --b1_iTH0PCNopWNcyRHovrIxxPkmmXyFEsRuJS5y71D64 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPlJ1c3QncyBwb29yIGVjb3N5c3RlbSBhbmQgbGFjayBvZiBhIHN0YW5kYXJk IGxpYnJhcnkgZG9lc24ndCByZWFsbHkgaGVscC48L3A+DQo8cCBkaXI9Imx0ciI+SXRzIGZhbnMg YXJlIGFsc28gYSBsb3VkIG1pbm9yaXR5LiBUaGUgc29vbmVyIHBlb3BsZSBzdGFydCBsb29raW5n IGF0IGl0IHRoZSBwcm9wZXIgd2F5LCBhcyBhIHRvb2wsIGJyaWdodGVyIGRheXMgZm9yIExpbnV4 IHdpbGwgY29tZS4gSG9wZWZ1bGx5IHRoZSB0aW1lIHdpbGwgY29tZSBmb3IgdGhhdC48L3A+DQo8 cCBkaXI9Imx0ciI+Rm9yIHRoZSB0aW1lIGJlaW5nLCBpdCB0cnVseSBpcyBhIGJ1cmRlbiB0aG91 Z2ghIEknZCBjYWxsIGl0IGFuIGludmVzdG1lbnQsIHBhdGllbmNlIHBlb3BsZSE8L3A+DQo8ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLS08YnI+T24gOS8zLzI0IDAxOjIzLCBUb21layBDRURSTyA8dG9tZWtAY2Vkcm8u aW5mbz4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48ZGl2 IGRpcj0iYXV0byI+PGRpdiBkaXI9ImF1dG8iPjxkaXYgZGlyPSJhdXRvIj5SdXN0IGZvciBMaW51 eCBtYWludGFpbmVyIHN0ZXBzIGRvd24gaW4gZnJ1c3RyYXRpb24gd2l0aCAmIzM5O25vbnRlY2hu aWNhbCBub25zZW5zZSYjMzk7LjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBk aXI9ImF1dG8iPkNvbW11bml0eSBzZWVtcyB0byBDIFJ1c3QgbW9yZSBhcyBhIGJ1cmRlbiB0aGFu IGEgYmVuZWZpdDwvZGl2PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdj48YSBo cmVmPSJodHRwczovL3d3dy50aGVyZWdpc3Rlci5jb20vMjAyNC8wOS8wMi9ydXN0X2Zvcl9saW51 eF9tYWludGFpbmVyX3N0ZXBzX2Rvd24vIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVy Ij5odHRwczovL3d3dy50aGVyZWdpc3Rlci5jb20vMjAyNC8wOS8wMi9ydXN0X2Zvcl9saW51eF9t YWludGFpbmVyX3N0ZXBzX2Rvd24vPC9hPjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRh dGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPi0tPGJyPkNlRGVST00sIFNRN01IWiwgPGEg aHJlZj0iaHR0cDovL3d3dy50b21lay5jZWRyby5pbmZvIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu b3JlZmVycmVyIj5odHRwOi8vd3d3LnRvbWVrLmNlZHJvLmluZm88L2E+PC9kaXY+PC9kaXY+DQo8 L2Jsb2NrcXVvdGU+PC9kaXY+ --b1_iTH0PCNopWNcyRHovrIxxPkmmXyFEsRuJS5y71D64-- From nobody Mon Sep 2 22:49:56 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 4WyP8x2Zp3z5VBhn for ; Mon, 02 Sep 2024 22:50:09 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyP8x1g9Rz4YLJ; Mon, 2 Sep 2024 22:50:09 +0000 (UTC) (envelope-from joesuf4@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-42bb885f97eso22850165e9.0; Mon, 02 Sep 2024 15:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725317408; x=1725922208; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ApFqiVrcnvWwx/TJeH4fafA7yhoKeI+f2cuwdkZGUYg=; b=Bs0AUJxkVKFaPsS9RIk1nA5kpOugRsrkUqv293l0XsARPL+kt3p1Paq0dsMC1xJbHK je5yOeHn/3PKZN93nOhhpzo/ysBo/deYl/efKn+BAy8rE8VjGVZCuvi8rrqeIwh7J759 l1D2IeCuHldVu5Dw1ipejnt/gMHPNVnzIpxRqaQjObGAVE2eV1mJ3xAy5ewnSOarCRae dUMnnk+UK83qXxAS5AqUtiNhwTumzYqF/m3OArru4fka7nLbHeZ+FK6LwDM34wUOzj+6 Vr/YkD3n3p0exHV25aN6pe01ym1rzjjbrZL3vHk5mHWIFw6RZ/fviWPp/2k1G+1VqFFH Va8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725317408; x=1725922208; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ApFqiVrcnvWwx/TJeH4fafA7yhoKeI+f2cuwdkZGUYg=; b=iUnLio+mTw7S5MFxnhvoulVvgGIsXDoiLmRsnOa1Lqtte3sC3mjTQIdf6fQQjkEqmP AJ7iY9Xbmsq8axU4ZRC7sM1Z2fUZmNyo7+2paWqi392jNkkdTP30NokwOKlU9bn0HqVx hppn1z+nCMn4pAzoxeXmVSGUKhMKY5FiJBGbALdsQq923d8EwNNK0AShmoDdsDlMfrsT uaoFI5crFxWapkTmUjHIT1zFGTAgxsQ4l11xMCHojwnnqZzvvGa+wLsdz8pLJfcJOTHG wwvBTar013ihmmqdsFw4hg+HPjtUteJ3XseXW9WqI0HdmD6AU5YhwLqsZZ6vdN4N0aX3 Xu2Q== X-Forwarded-Encrypted: i=1; AJvYcCU1f9Q3hZC39IETKtfZFNLzOG0z7DwCTGzz3x13AnyVg8SlptheaWse3yBt8KEVdzkCEGQ6+6tsbqaFClSzLQAO@freebsd.org, AJvYcCXx5AdvWE56im6CDN+r/8R6iwDMhis9o3JkXWXTa4LxBG+DgbEllxgx4Krlp6ojodH9Smd4OJmr@freebsd.org X-Gm-Message-State: AOJu0YxjTmNLmfEeicYiz38ED7DvgIGUB3XyCXCjzsBx0wyO48kct2xw Pa+yVkZyREwlQEWeF2ZjA8gTkm2vlPE+3UqYY5BMYmU+SGREZ3m9I7roEUQEZ6y2CfsGKg3hQpK s6HplrqM6BSRrFjMnh3upMfuN00I= X-Google-Smtp-Source: AGHT+IG4dQyowO8TSx1QuFPhmAImhI4y/6j6oI1Hd2Gey/XB5uhY3UgINgGheFpbyNVcwhByxS2jlJ4Tu60ir//A9/Y= X-Received: by 2002:a5d:59a7:0:b0:374:c878:21f7 with SMTP id ffacd0b85a97d-374c87823fcmr3917152f8f.10.1725317407535; Mon, 02 Sep 2024 15:50:07 -0700 (PDT) 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 References: In-Reply-To: From: Joe Schaefer Date: Mon, 2 Sep 2024 18:49:56 -0400 Message-ID: Subject: Re: The Case for Rust (in the base system) To: fvalasiad Cc: "tomek@cedro.info" , "freebsd-hackers@freebsd.org" , "imp@bsdimp.com" , "asomers@freebsd.org" , Konstantin Belousov Content-Type: multipart/alternative; boundary="0000000000003378f906212ac380" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4WyP8x1g9Rz4YLJ --0000000000003378f906212ac380 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is a shitty tool by engineering standards, because it is 1/ nonportable, 2/ non backwards compatible, 3/ immature (compiler segfaults). The world can wait for the tool to stabilize in order to get wide scale adoption. On Mon, Sep 2, 2024 at 6:30=E2=80=AFPM fvalasiad wrot= e: > Rust's poor ecosystem and lack of a standard library doesn't really help. > > Its fans are also a loud minority. The sooner people start looking at it > the proper way, as a tool, brighter days for Linux will come. Hopefully t= he > time will come for that. > > For the time being, it truly is a burden though! I'd call it an > investment, patience people! > > > -------- Original Message -------- > > On 9/3/24 01:23, Tomek CEDRO wrote: > > Rust for Linux maintainer steps down in frustration with 'nontechnical > nonsense'. > > Community seems to C Rust more as a burden than a benefit > > > https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_do= wn/ > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > --0000000000003378f906212ac380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is a shitty tool by engineering standards, because it = is=C2=A0

1/ nonportable,=
2/ non backwards compatible,
3/ immature (compiler segfaults).

The world can wait for the tool to stabilize in order to get wid= e scale adoption.

On Mon, Sep 2, 2024 at 6:30=E2=80=AFPM fvalasiad <= fvalasiad@proton.me> wrote:

Rust's poor ecosy= stem and lack of a standard library doesn't really help.

Its fans are also a loud minority. The sooner people start l= ooking at it the proper way, as a tool, brighter days for Linux will come. = Hopefully the time will come for that.

For the time being, it truly is a burden though! I'd cal= l it an investment, patience people!



-------- Original Message --------

On 9/3/24 01:= 23, Tomek CEDRO wrote:
Rust for Linux maintainer steps down in frustratio= n with 'nontechnical nonsense'.

Community seems to C Rust more as a burden than a benefit


--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--0000000000003378f906212ac380-- From nobody Mon Sep 2 23:39: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 4WyQGD3vRnz5VFq3 for ; Mon, 02 Sep 2024 23:39:48 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyQGC6f3nz4cqZ; Mon, 2 Sep 2024 23:39:47 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725320379; x=1725987045; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=biG245h7AboEg3Yc8FBZRqWj06NJGMAkS63vZNi/Wqo=; b=I+0ngJSegMdSgXz81A++ovQPCULkp6jkeyerP5HkKt3aWaxnA3E4qRqI2CEf4X+d3qpGlYbV +/D+VeyLRMADiC5la3uvAPm/CRSzfqSLq97W0g43iMnbIGIyAVEPUtvgeQlSuHMzF2UCxonsoa 6mj35O4DY/dwHIZCShQC0qgBC9zPMEc9dX/dgnf8BiGcx003jBnCtn2Ue6kFi9VicpqdXaMHJu 1/TE5wiJ1Bxz0zsSB5S/57raUTPVCv0eEd94dEJbs7PSg4+mZaGnvLeKFWoxBr+P+HDAqc39H/ 9+uKM8ltzW7fFZCVFPkypY3Ih3lyEkEU7YdNdkCvCVnCnojg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725320379; x=1725987045; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=biG245h7AboEg3Yc8FBZRqWj06NJGMAkS63vZNi/Wqo=; b=HIgaMSAW09jVgwKeRAfp5QVcI3fh9Gt432Ov6CPiNJCO9r/saHBKLw3xCcv8LD/11xiq3x82 kDM9C7MM64ykDA== Date: Tue, 03 Sep 2024 01:39:38 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Tomek CEDRO Cc: FreeBSD Hackers , Warner Losh , Alan Somers , Konstantin Belousov Subject: Re: The Case for Rust (in the base system) Message-ID: <20240902233938.Am-uAUr_@steffen%sdaoden.eu> In-Reply-To: References: User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4WyQGC6f3nz4cqZ 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 Tomek CEDRO wrote in : |Rust for Linux maintainer steps down in frustration with 'nontechnical |nonsense'. | |Community seems to C Rust more as a burden than a benefit All these filesystem maintainers said that if they fix bugs and do stuff, they do that in C, and the Rust layer has to follow, as opposed to the opposite, ie, that the filesystem maintainers must henceforth fix bugs and do development in a way that matches Rust expectations .. which i find somehow understandable. (Not even taking T'so's "writing a filesystem is easy, but creating a [enterprise] filesystem is very, very difficult (and i know what i am talking about / i know that by experience / xy)" is more or less a quote of him. Exchange "enterprise" with something of that level, you know. Wait, i can search for the email. For example Date: Sun, 29 Aug 2021 23:14:28 -0400 Message-ID: The ext2/ext3/ext4 file system utilities is as far as I know the first fsck that was developed with a full regression test suite from the very beginning and integrated into the sources. (Just run "make check" and you'll know if you broken something --- or it's how I know the person contributing code was sloppy and didn't bother to run "make check" before sending me patches to review....) What a lot of people don't seem to understand is that file system utilities are *important*, and more work than you might think. The ext4 file system is roughly 71 kLOC (thousand lines of code) in the kernel. E2fsprogs is 340 kLOC. In contrast, the btrfs kernel code is 145 kLOC (btrfs does have a lot more "sexy new features"), but its btrfs-progs utilities is currently only 124 kLOC. And the e2fsprogs line count doesn't include the 350+ library of corrupted file system images that are part of its regression test suite. Btrfs has a few unit tests (as does e2fsprogs), but it doesn't have any thing similar in terms of a library corrupted file system images to test its fsck functionality. (Then again, neither does the file system utilities for FFS, so a regression test suite is not required to create a high quality fsck program. In my opinion, it very much helps, though!) [.] I was present at the very beginning of btrfs. In November, 2007, various file system developers from a number of the big IBM companies got together (IBM, Intel, HP, Red Hat, etc.) and folks decided that Linux "needed an answer to ZFS". In preparation for that meeting, I did some research asking various contacts I had at various companies how much effort and how long it took to create a new file system from scratch and make it be "enterprise ready". I asked folks at Digital how long it took for advfs, IBM for AIX and GPFS, etc., etc. And the answer I got back at that time was between 50 and 200 Person Years, with the bulk of the answers being between 100-200 PY's (the single 50PY estimate was an outlier). This was everything --- kernel and userspace coding, testing and QA, performance tuning, documentation, etc. etc. The calendar-time estimates I was given was between 5-7 calendar years, and even then, users would take at least another 2-3 years minimum of "kicking the tires", before they would trust *their* precious enterprise data on the file system. There was an Intel engineer at that meeting, who shall remain nameless, who said, "Don't tell the managers that or they'll never greenlight the project! Tell them 18 months...." And so I and other developers at IBM, continued working on ext4, which we never expected would be able to compete with btrfs and ZFS in terms of "sexy new features", but our focus was on performance, scalability, and robustness. And it probably was about 2015 or so that btrfs finally became more or less stable, but only if you restricted yourself to core functionality. (e.g., snapshots, file-system level RAID, etc., was still dodgy at the time.) I will say that at Google, ext4 is still our primary file system, mainly because all of our expertise is currently focused there. We are starting to support XFS in "beta" ("Preview") for Cloud Optimized OS, since there are some enterprise customers which are using XFS on their systems, and they want to continue using XFS as they migrate from on-prem to the Cloud. We fully support XFS for Anthos Migrate (which is a read-mostly workload), and we're still building our expertise, working on getting bug fixes backported, etc., so we can support XFS the way enterprises expect for Cloud Optimized OS, which is our high-security, ChromeOS based Linux distribution with a read-only, cryptographically signed root file system optimized for Docker and Kubernetes workloads. I'm not aware of any significant enterprise usage of btrfs, which is why we're not bothering to support btrfs at $WORK. The only big company which is using btrfs in production that I know of is Facebook, because they have a bunch of btrfs developers, but even there, they aren't using btrfs exclusively for all of their workloads. My understanding of why Fedora decided to make btrfs the default was because they wanted to get more guinea pigs to flush out the bugs. Note that Red Hat, which is responsible for Red Hat Enterprise Linux (their paid product, where they make $$$) and Fedora, which is their freebie "community distribution" --- Well, Red Hat does not currently support btrfs for their RHEL product. Make of that what you will.... As well as Date: Sun, 29 Aug 2021 23:46:47 -0400 Message-ID: [.] Actually, the btrfs folks got that from ext2/ext3/ext4. The original behavior was "don't worry, be happy" (log errors and continue), and I added two additional options, "remount read-only", and "panic and reboot the system". I recommend the last especially for high availability systems, since you can then fail over to the secondary system, and fsck can repair the file system on the reboot path. The primary general-purpose file systems in Linux which are under active development these days are btrfs, ext4, f2fs, and xfs. They all have slightly different focus areas. For example, f2fs is best for low-end flash, the kind that is find on $30 dollar mobile handsets on sale in countries like India (aka, "the next billion users"). It has deep knowledge of "cost-optimized" flash where random writes are to be avoided at all costs because write amplification is a terrible thing with very primitive FTL's. For very large file systems (e.g., large RAID arrays with pedabytes of data), XFS will probably do better than ext4 for many workloads. Btrfs is the file systems for users who have ZFS envy. I believe many of those sexy new features are best done at other layers in the storage stack, but if you *really* want file-system level snapshots and rollback, btrfs is the only game in town for Linux. (Unless of course you don't mind using ZFS and hope that Larry Ellison won't sue the bejesus out of you, and if you don't care about potential GPL violations....) Ext4 is still getting new features added; we recently added a light-weight journaling (a simplified version of the 2017 Usenix ATC iJournaling paper[1]), and just last week we've added parallelized orphan list called Orphan File[2] which optimizes parallel truncate and unlink workloads. (Neither of these features are enabled by default yet, because maybe in a few years, or earlier if community distros want to volunteer their users to be guinea pigs. :-) [1] https://www.usenix.org/system/files/conference/atc17/atc17-park.pdf [2] https://www.spinics.net/lists/linux-ext4/msg79021.html We currently aren't adding the "sexy new features" of btrfs or ZFS, but that's mainly because there isn't a business justification to pay for the engineering effort needed to add them. I have some design sketches of how we *could* add them to ext4, but most of the ext4 developers like food with our meals, and I'm still a working stiff so I focus on work that adds value to my employer --- and, of course, helping other ext4 developers working at other companies figure out ways to justify new features that would add value to *their* employers. I might work on some sexy new features if I won the Powerball Lottery and could retire rich, or I was working at company where engineers could work on whatever technologies they wanted without getting permission from the business types, but those companies tend not to end well (especially after they get purchased by Oracle....) Ok granted that is not what i said, but i am sure there was something around that lines in some message at some time.) |https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_d\ |own/ |-- |CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ... --End of --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Sep 2 23:56:24 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 4WyQdX42Qsz5VGvt for ; Mon, 02 Sep 2024 23:56:32 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyQdW5sfjz4fsR for ; Mon, 2 Sep 2024 23:56:31 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725321389; x=1725580589; bh=l20GtuxvuQDfEMjmdfB1mV0/HEFLD4FLIBwQkyDEX8g=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=OQbOcA/H3dGT2uAkKfpOFBMdb19rkxjROLN+7APFs7Y+qNFHc/xmFZe9sPDv3bVDM Yq6aShvGU3PgFPmp40ybpu1M8+xXNUAfx4kti1391c2PS1amVwwLE3aYSneei68CQJ MJ0eX1wgQdBtiwiYKcZYb8auMQyoLpCKf3g0UZcdU8+wm24OzDvjBkfoyPbrac2ic4 2S0VTJegUAjbYqqRrASJSVV1P0dlzP8KDyim7o/O4UwYsl03pDc2mCcW1sEVEel5Uw 5rKKc6gEiL5qeOUCgYZ/G7rl8Gq20b/+NPfeTj+fFQX64Yk8ziU0ANbZ6xvtt75nlp Hj2Q9zPdDGGdA== Date: Mon, 02 Sep 2024 23:56:24 +0000 To: "steffen@sdaoden.eu" , "tomek@cedro.info" From: fvalasiad Cc: "freebsd-hackers@freebsd.org" , "imp@bsdimp.com" , "asomers@freebsd.org" , Konstantin Belousov Subject: Re: The Case for Rust (in the base system) Message-ID: In-Reply-To: <20240902233938.Am-uAUr_@steffen%sdaoden.eu> References: <20240902233938.Am-uAUr_@steffen%sdaoden.eu> Feedback-ID: 78761413:user:proton X-Pm-Message-ID: 7e0cdfae9c4be2f1c9c158d9552ac433c3aa3875 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4WyQdW5sfjz4fsR Fedora defaulting to btrfs because they treat their users as guinea pigs is= a rather dramatic way to put it. By definition anyone which uses a rolling distro is a guinea pig, and it's = not really a bad thing since people know and choose this. Ubuntu non LTS releases are just the same. Additionally, people let warnings go through their patches(mind you, withou= t Wall/Wextra/Wpedantic enabled), let alone not run "make check". If only people bothered using the mature ecosystem of tools around C. -------- Original Message -------- On 9/3/24 02:39, Steffen Nurpmeso wrote: > Tomek CEDRO wrote in > : > |Rust for Linux maintainer steps down in frustration with 'nontechnical > |nonsense'. > | > |Community seems to C Rust more as a burden than a benefit > =20 > All these filesystem maintainers said that if they fix bugs and do > stuff, they do that in C, and the Rust layer has to follow, as > opposed to the opposite, ie, that the filesystem maintainers must > henceforth fix bugs and do development in a way that matches Rust > expectations .. which i find somehow understandable. > =20 > (Not even taking T'so's "writing a filesystem is easy, but > creating a [enterprise] filesystem is very, very difficult (and > i know what i am talking about / i know that by experience / xy)" > is more or less a quote of him. > Exchange "enterprise" with something of that level, you know. > Wait, i can search for the email. For example > =20 > Date: Sun, 29 Aug 2021 23:14:28 -0400 > Message-ID: > =20 > The ext2/ext3/ext4 file system utilities is as far as I know the first > fsck that was developed with a full regression test suite from the > very beginning and integrated into the sources. (Just run "make > check" and you'll know if you broken something --- or it's how I know > the person contributing code was sloppy and didn't bother to run > "make check" before sending me patches to review....) > =20 > What a lot of people don't seem to understand is that file system > utilities are *important*, and more work than you might think. The > ext4 file system is roughly 71 kLOC (thousand lines of code) in the > kernel. E2fsprogs is 340 kLOC. In contrast, the btrfs kernel code is > 145 kLOC (btrfs does have a lot more "sexy new features"), but its > btrfs-progs utilities is currently only 124 kLOC. > =20 > And the e2fsprogs line count doesn't include the 350+ library of > corrupted file system images that are part of its regression test > suite. Btrfs has a few unit tests (as does e2fsprogs), but it doesn't > have any thing similar in terms of a library corrupted file system > images to test its fsck functionality. (Then again, neither does the > file system utilities for FFS, so a regression test suite is not > required to create a high quality fsck program. In my opinion, it > very much helps, though!) > [.] > I was present at the very beginning of btrfs. In November, 2007, > various file system developers from a number of the big IBM companies > got together (IBM, Intel, HP, Red Hat, etc.) and folks decided that > Linux "needed an answer to ZFS". In preparation for that meeting, I > did some research asking various contacts I had at various companies > how much effort and how long it took to create a new file system from > scratch and make it be "enterprise ready". I asked folks at Digital > how long it took for advfs, IBM for AIX and GPFS, etc., etc. And the > answer I got back at that time was between 50 and 200 Person Years, > with the bulk of the answers being between 100-200 PY's (the single > 50PY estimate was an outlier). This was everything --- kernel and > userspace coding, testing and QA, performance tuning, documentation, > etc. etc. The calendar-time estimates I was given was between 5-7 > calendar years, and even then, users would take at least another 2-3 > years minimum of "kicking the tires", before they would trust *their* > precious enterprise data on the file system. > =20 > There was an Intel engineer at that meeting, who shall remain > nameless, who said, "Don't tell the managers that or they'll never > greenlight the project! Tell them 18 months...." > =20 > And so I and other developers at IBM, continued working on ext4, which > we never expected would be able to compete with btrfs and ZFS in terms > of "sexy new features", but our focus was on performance, scalability, > and robustness. > =20 > And it probably was about 2015 or so that btrfs finally became more or > less stable, but only if you restricted yourself to core > functionality. (e.g., snapshots, file-system level RAID, etc., was > still dodgy at the time.) > =20 > =20 > I will say that at Google, ext4 is still our primary file system, > mainly because all of our expertise is currently focused there. We > are starting to support XFS in "beta" ("Preview") for Cloud Optimized > OS, since there are some enterprise customers which are using XFS on > their systems, and they want to continue using XFS as they migrate > from on-prem to the Cloud. We fully support XFS for Anthos Migrate > (which is a read-mostly workload), and we're still building our > expertise, working on getting bug fixes backported, etc., so we can > support XFS the way enterprises expect for Cloud Optimized OS, which > is our high-security, ChromeOS based Linux distribution with a > read-only, cryptographically signed root file system optimized for > Docker and Kubernetes workloads. > =20 > I'm not aware of any significant enterprise usage of btrfs, which is > why we're not bothering to support btrfs at $WORK. The only big > company which is using btrfs in production that I know of is Facebook, > because they have a bunch of btrfs developers, but even there, they > aren't using btrfs exclusively for all of their workloads. > =20 > My understanding of why Fedora decided to make btrfs the default was > because they wanted to get more guinea pigs to flush out the bugs. > Note that Red Hat, which is responsible for Red Hat Enterprise Linux > (their paid product, where they make $$$) and Fedora, which is their > freebie "community distribution" --- Well, Red Hat does not currently > support btrfs for their RHEL product. > =20 > Make of that what you will.... > =20 > As well as > =20 > Date: Sun, 29 Aug 2021 23:46:47 -0400 > Message-ID: > =20 > [.] > Actually, the btrfs folks got that from ext2/ext3/ext4. The original > behavior was "don't worry, be happy" (log errors and continue), and I > added two additional options, "remount read-only", and "panic and > reboot the system". I recommend the last especially for high > availability systems, since you can then fail over to the secondary > system, and fsck can repair the file system on the reboot path. > =20 > =20 > The primary general-purpose file systems in Linux which are under > active development these days are btrfs, ext4, f2fs, and xfs. They > all have slightly different focus areas. For example, f2fs is best > for low-end flash, the kind that is find on $30 dollar mobile handsets > on sale in countries like India (aka, "the next billion users"). It > has deep knowledge of "cost-optimized" flash where random writes are > to be avoided at all costs because write amplification is a terrible > thing with very primitive FTL's. > =20 > For very large file systems (e.g., large RAID arrays with pedabytes of > data), XFS will probably do better than ext4 for many workloads. > =20 > Btrfs is the file systems for users who have ZFS envy. I believe many > of those sexy new features are best done at other layers in the > storage stack, but if you *really* want file-system level snapshots > and rollback, btrfs is the only game in town for Linux. (Unless of > course you don't mind using ZFS and hope that Larry Ellison won't sue > the bejesus out of you, and if you don't care about potential GPL > violations....) > =20 > Ext4 is still getting new features added; we recently added a > light-weight journaling (a simplified version of the 2017 Usenix ATC > iJournaling paper[1]), and just last week we've added parallelized > orphan list called Orphan File[2] which optimizes parallel truncate > and unlink workloads. (Neither of these features are enabled by > default yet, because maybe in a few years, or earlier if community > distros want to volunteer their users to be guinea pigs. :-) > =20 > [1] https://www.usenix.org/system/files/conference/atc17/atc17-park.pd= f > [2] https://www.spinics.net/lists/linux-ext4/msg79021.html > =20 > We currently aren't adding the "sexy new features" of btrfs or ZFS, > but that's mainly because there isn't a business justification to pay > for the engineering effort needed to add them. I have some design > sketches of how we *could* add them to ext4, but most of the ext4 > developers like food with our meals, and I'm still a working stiff so > I focus on work that adds value to my employer --- and, of course, > helping other ext4 developers working at other companies figure out > ways to justify new features that would add value to *their* > employers. > =20 > I might work on some sexy new features if I won the Powerball Lottery > and could retire rich, or I was working at company where engineers > could work on whatever technologies they wanted without getting > permission from the business types, but those companies tend not to > end well (especially after they get purchased by Oracle....) > =20 > Ok granted that is not what i said, but i am sure there was > something around that lines in some message at some time.) > =20 > |https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps= _d\ > |own/ > |-- > |CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > ... > --End of .com> > =20 > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > =20 > From nobody Tue Sep 3 06:33:32 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 4WybPh4qVXz5W2d1 for ; Tue, 03 Sep 2024 06:31:52 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic310-57.consmr.mail.ir2.yahoo.com (sonic310-57.consmr.mail.ir2.yahoo.com [77.238.177.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WybPg3J35z4PS8 for ; Tue, 3 Sep 2024 06:31:51 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tN1Wxuid; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of anthony.pankov@yahoo.com designates 77.238.177.30 as permitted sender) smtp.mailfrom=anthony.pankov@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725345109; bh=r4ztI7ZgQziJV9X+NBvXp3tFr0riolerEyRQBuVevek=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject:Reply-To; b=tN1WxuidP+OQ9Tr2McBWvTfFNHG7FEoWEos4Kxxp3co+hks1CGehfvejaDd+GrunqtDmko2E/cYBko3HE4Jjb5eqMVy3ewym7XiAW3pA4IM0kjvVudOZWeffCV34/ZFtTeFxAvJRSjUP/r9JvxKQ9ya9zeoyn4TSX8rvIRURCRI2/A2oMf+bAIwUngdC5JeY5I5oPj4/Fqft0JyjWzVnV2N2YejxazqOAUIVrLiirddK7t+QtvY0k2JSs/2+ty/AXv8p6Op9EBWyzkIk9ImPhfZaFtA2BA6haXDjVzNbyBqRVU07l3Ybfc+RYcoqj02aYZsJjKuCqiX+oO4Y9w8/fA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725345109; bh=Iku9XpfegmDjVOOmFw+put8ZDGsgNdn70zMZ2RAIt/T=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=VcIeQmFCtP+TtUDosuJXyqRFdIiTm7vVX9udx0jmkDNf8UH0ZrvIkw+2fmHQEhOs3mlf3P1YwfQONPRRuLhEgSjbGmOyo3INoVusPNtvdkfOsa3+QEzLfq4AthW1legzdQ4znEMJxmY7qHvMk+e9+OdRBItbciKlT5yXhzyLJjxlDzdX1JYVt4JqPC4mXM/ixClUiXHl5cxDd11YvDoRMb3bIYmO7supBbCaskeArgQq8AoP5JRZmncoaTBPdbUWSbRRxibjiDmGq9sk3A9eOQA34u/Keq04Wrmr5eEz5aF/fKjM+xOi2cFCeVCdVcSk/P9UDZL4YT0M2/mPzejfnA== X-YMail-OSG: Ty6KskYVM1ljKxqaOBBPExMptIl9RfoNLJlHokJG1cASnAcCh0.zA7ioHYrEetH J3wbhASMu29d8U.O5YZ2gPCT4Frb0AW12CIUExTgObzn4Qwg2CxMvIK6E10Bs92S7ktz7rdk5Det iqMNou1ioyeY16jswnnWEKdb0BlaPCmLfeGwAk.sZ.PFzToYHYNc3XnAlanq4anGFquzlN2Cub1V 9Rwzd3kA5oAKTTWgnUSR4zYsMDdC2PpJMc.YzqmFKsSi9PxOA1ywmZ39oSCACwOQyu7PZhFuCe8_ LfxCHWV_BpCMat6Ax8.UV63Bq8zleg_XMA8jnQKeSJpCFUczQyyonU2mTtmuD9UEfvG0jk2DBzXF 2MXo3D0ZN4Oz8hDWMJPV7uKonumcKvXLvlaFPf5j1szn6.uv7tx5la5eYBBLsfSx7oJbHKAHTAtQ cO9Xnq61sdtdKun.LneZPdxhRs8txP6ZnXnkkyJnsLaa75RcO6P0pfJX0YllKXJKUW87kLjKeX5G CLBgFfXV0EIggGBFT5oZPVj1.MItfL9_SzQz0JpgElLOIm6Qj2_8OUpllTKV.cPHspYwJ_528eZ5 T6Xm45NPfJglBVSlNOFvQXCSNaiTgQAh8ZWUHjh_kHYoOnZ_7.wCpfwDL4dZlDfyEKo0.2.mYySC Fiv8NJeXSox9VhIg1nTcOs2jF7s6zd7JvUmEDMM9e4xPNIegobTtkOIXBScHngta.ButV87YXGum .4HuZCxphJALGQAgPBM.P3lstt6_OJWJjcXDxW2cq9H9jlOSU5ENkJGrljKTD0tECQMMYJFxG0.8 z8Lb8Il9pMrZkRIUxCuwDg_4lZ.4NOR6hk9IXfxoSTnCD7ZXCQypf9JUW5jInF4oDl3quS0ZUFXY 69h..a26MMi4W28.rPe.ZZ8En5sI9vLQVa9oVLUGpBrSDViptlqKFdH6.gSXzDP7ez1ERi9lQmBd g.jaUuIiIflT.UWW3ZlFFtAPlmsNcWUbYXN31ah8z_tVhIz4RUZO3Gcp777n7CgzCuyFer5Try3j pwIdunQkDIlpeAJZ5XVE9VZMRXDjlbXnakfchlN4.tRdj74h0HY41neSZRwek3IK5GY2mbNOB8eX 7FrCP8Nau9THe2_uZLh8ZvxssE6yHJwy6XihQKCoDoJOPyZQ4Qce5_MHZ0bIzaLlS336w5OHz06W OpEwFKlv3dr0VqVaLZYqCwmsu3aRK8yHstE88lB8oeELQqMRUe3esk14tB_Wx1ph5QKOwyIsTL3x CnHcGQtDy6lZvTOwXprYH4z8CCJzjNfnkstdFyPbeIPLPUiqJkbJcqkuYN2fwtxzzXW8OcBt17rw QzlA6kOO_fAIHmsKj6e4LOYRyGRHWq47XLywhTYoFBg9dOxEJsCkmNK39cDU.btZjaJncWso3Fv7 IhSmdN8iQG9HMq6QyiqqBSJ2_d7g7BWQx0uhRZUk11q0jygluSrVgkRIZ.Vet77.cW3qyOxec7MI yrbB8UPjVsHuGfVFBiC8OuK2ZKri0O49kK2eY_DU2_Hh6e6m1TtaV1cl6ShhmQrb2mlDoqwe6BYn 7T8hszpyZzmWxhvnGzMgRAPLsxYjoKleqc2iYTqAiTkuK31mfqLrJkwdl37EJ07iFXR0WhXmxBsl NT16aq1kQHAtOAdawJp9cVG1LyVdK9fV8gH9hcQ9Lhf7VlYQjru9uhAFswd9a6e7aGjTxC3hdIkw hSmFbUiM0Tk37BKJhTKPRREwMawohQMw3Xdwd1cfuhrHF5TPeAiUC5rJRJz00gCq9pf12flolNvn e_MCWV5zcKcbL9BHtrqa8zK3nylqneEa90S1_2EVoHbsAlMuvUdKdI_B39PINy4_0YqXJtJ2vNxg p.Rn2uePFhQackMnCUSoWqXRkGQQCRjTzdnrstpevRDfdF2eCEvz4Er1iBUlrSYgwLBv.YlefuZB qzzMTGNt3qMHY5wuK3vskozzEbfKHXLb.Sm0uiYWKE1pzHH2eOT9Bdm6lb_zDgcDBKUizcDBC51P V2__dloS5JfrZ.mtM4s2QRGJFOlBGUkmB0zd.DQI48CIq8vkpqulfMH8KGHbrHkDzRBJQ88BZh6K sHBGNBFFZeTfoZRLDJZRpREtHtHbcNTjFwumeWdhRoVsqmE1u8.SF00sY0wVYmbwHNYyqKis3PQn KhL7zoZ_03zPOLdYB8zR1yo9cynSVFduSja0sY3dP4cyLA1hCjazL9rFqQmiV X-Sonic-MF: X-Sonic-ID: f89cdfe4-890d-44c7-acbb-f40f31b42a11 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Tue, 3 Sep 2024 06:31:49 +0000 Received: by hermes--production-ir2-6664f499fc-gccss (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 30612d43aa0ec9e27a40b362ecb6957d; Tue, 03 Sep 2024 06:31:43 +0000 (UTC) Date: Tue, 3 Sep 2024 09:33:32 +0300 From: Anthony Pankov Message-ID: <1876116975.20240903093332@yahoo.com> To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org Subject: Re: makefs -t ffs makes too large image In-Reply-To: References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> <334195982.20240822182405@yahoo.com> <70579701-7457-46b1-9329-a51eddec51de@aetern.org> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.81 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.806]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[77.238.177.30:from]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+] X-Rspamd-Queue-Id: 4WybPg3J35z4PS8 Hello Daniel, My impression that compression makes ZFS slower on VM. May be this is the only case of not so-well-optimized VM such as QEMU on Windows. Sunday, September 1, 2024, 11:50:16 PM, you wrote: > On Fri, Aug 23, 2024 at 12:39:26AM UTC, Yuri Pankov wrote: >>Anthony Pankov wrote: >>> Hello Miroslav, >>> >>> You are genius! >>> >>> But the situation is a very frustrating. It is a default system and I did nothing to turn the compression on. >>> So I was absolutely sure that compression is off. >>> >>> I'm sorry. >>> Nevertheless having compression on by default is a very weird decision and is fully unexpected for me. I've never seen a big warning about default value of this vital parameter will be inverted. >>> >>> On 12 -STABLE: >>> >>> # zfs get compression >>> NAME PROPERTY VALUE SOURCE >>> ps2 compression off default >>> >>> On 14-STABLE >>> >>> # zfs get compression >>> NAME PROPERTY VALUE SOURCE >>> tank compression on default >>> tank/bsdsrc compression on default >> >>It came in with the following openzfs commit and probably no one really >>noticed as installer turns on compression by default, so I was going to >>say it was always that way until I looked up the change :-) >> >>commit 56fa4aa96eb3875f254e93eaef646ea20ba187f9 >>Author: Rich Ercolani >>Date: Thu Mar 3 13:43:38 2022 -0500 >> >> Default to ON for compression >> >> A simple change, but so many tests break with it, >> and those are the majority of this. >> >> Reviewed-by: George Melikov >> Reviewed-by: Brian Behlendorf >> Signed-off-by: Rich Ercolani >> Closes #13078 >> >>And it looks like it's in FreeBSD starting with 14.0: >> >>$ git branch -a --contains 56fa4aa96eb3875f254e93eaef646ea20ba187f9 >>* main >> remotes/origin/HEAD -> origin/main >> remotes/origin/main >> remotes/origin/pull/956/merge >> remotes/origin/releng/14.0 >> remotes/origin/releng/14.1 >> remotes/origin/stable/14 >> > Hi folks, > It's maybe also worth mentioning that compression by default makes > ZFS faster. > Allan Jude had some numbers for the default (lz4) in the > presentation he did while implementing zstd[1]. > It can be a bit surprising though, but hopefully it's a good one.;) > Yours, > Daniel Ebdrup Jensen > 1: https://papers.freebsd.org/2018/bsdcan/jude-zfs_zstd/ -- Best regards, Anthony From nobody Tue Sep 3 07:07:45 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 4WycCC6lm9z5MQdL for ; Tue, 03 Sep 2024 07:07:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WycCB1FgHz4SFq for ; Tue, 3 Sep 2024 07:07:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 0A458892BB for ; Tue, 03 Sep 2024 07:07:45 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48377j1w000164; Tue, 3 Sep 2024 07:07:45 GMT (envelope-from phk) Message-Id: <202409030707.48377j1w000164@critter.freebsd.dk> To: freebsd-hackers@freebsd.org Subject: EU's product liability directive (Was: Re: The Case for Rust (in the base system)) In-reply-to: From: "Poul-Henning Kamp" References: <20240902233938.Am-uAUr_@steffen%sdaoden.eu> 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: text/plain; charset="UTF-8" Content-ID: <162.1725347265.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 03 Sep 2024 07:07:45 +0000 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.96)[-0.964]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[phk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WycCB1FgHz4SFq fvalasiad writes: > If only people bothered using the mature ecosystem of tools around C. I know I have mentioned it before, but: = Software quality will go through a paradigm shift when the new EU product liability directive lands: (6) In order to ensure that the Union=E2=80=99s product liability regime is comprehensive, no-fault liability for defective products should apply to all movables, including software, including when they are integrated into other movables or installed in immovables. ("no-fault liability" means that the consumer does not need to show that the manufacturer knew or should have known about the defect, showing it is defect is enough.) A lot of the force behind this new directive is Microsofts "Even if our software caused a genocide because of the way we designed it, and we did that on purpose, you can only recover $5.00" license terms. The EU council of ministers still need to vote on it, but that is expected to be a formality, and then the EU member countries have two short years to put it into effect in their own legislation. The current text as it applies to FOSS has: (13) Free and open-source software, where the source code is openly shared and users can freely access, use, modify and redistribute the software or modified versions thereof, can contribute to research and innovation on the market. Such software is subject to licences that allow anyone the freedom to run, copy, distribute, study, change and improve the software. In order not to hamper innovation or research, this Directive should not apply to free and open-source software developed or supplied outside the course of a commercial activity, since products so developed or supplied are by definition not placed on the market. Developing or contributing to such software should not be understood as making it available on the market. Providing such. This is in particular the case for software on open repositories should not be considered as making it available on the market, unless this occurs in the course of a commercial activity. In principle, the supply of free and open-source software by non-profit organisations should not be considered as taking place in a business-related context, unless the supply occurs in the course of a commercial activity, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. However, where software is supplied in exchange for a price or personal data is used other than exclusively for improving the security, compatibility or interoperability of the software, and is therefore supplied in the course of a commercial activity, the Directive should apply. (13a) If free and open-source software supplied outside the course of a commercial activity is subsequently integrated by a manufacturer as a component into a product in the course of a commercial activity and that is therefore placed on the market, it would be possible to hold that manufacturer liable for damage caused by the defectiveness of such software, while not the manufacturer of the software itself because they would have not fulfilled the conditions of placing a product or component on the market. Full text: https://data.consilium.europa.eu/doc/document/ST-5809-2024-INIT/en/pdf As far as anybody will tell me, we should all be in the clear under article 13, as far as our activities relate to freebsd.org But 13a, means that anybody who sells a product built around FOSS is on the hook for defects in that FOSS software. FOSS software quality will come under a lot more scrutiny going forward. Poul-Henning PS: Here is one insurance company who finally got the memo a week ago: https://www.zurich.com/commercial-insurance/sustainability-and-insights/c= ommercial-insurance-risk-insights/risk-managers-must-prepare-now-for-eu-pr= oduct-liability-shakeup -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Tue Sep 3 07:29:50 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 4Wychp3N6dz5MSJM for ; Tue, 03 Sep 2024 07:30:02 +0000 (UTC) (envelope-from lain@fair.moe) Received: from mail.076.ne.jp (mail.076.ne.jp [45.76.218.69]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wychm3xqLz4Yd6 for ; Tue, 3 Sep 2024 07:30:00 +0000 (UTC) (envelope-from lain@fair.moe) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=076.ne.jp header.s=dkim header.b=fy3Ls62d; dmarc=none; spf=none (mx1.freebsd.org: domain of lain@fair.moe has no SPF policy when checking 45.76.218.69) smtp.mailfrom=lain@fair.moe Received: from mail.076.ne.jp (localhost [127.0.0.1]) by mail.076.ne.jp (Postfix) with ESMTP id 4Wychb6WylzW0p7 for ; Tue, 3 Sep 2024 16:29:51 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=076.ne.jp; h= user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:to:from:date; s= dkim; t=1725348590; x=1727940591; bh=eAia27oxSuIs6fX38Qz46PX8W0S nath3ZEQSx6vu7xA=; b=fy3Ls62dRLiJynyPDB/FIJV4iyHTfxhIywdIfb+MUon xXqoqJqUbKjbXwnoGUByfIN0BOgfJnOAjDShrNke74Q86zUx2gdDeGAjYMYyhku5 PdQqTltNKOmUqso1Nzf74IfaIpgNrFpq8slQ8NA2NAUu/PXCp0BjUL8iC1Qxlgz5 UYlT0+pS/BJIDeK5nL3hMR9C3HDieH7FgMVY5bSkBJJDzQg3bilbiHwxyFIZBzTO 5M2qr9tGRV232BmwvZ6oIHgYljew8g6my7sPyRh+W3F1iVZt9hC8rV6Rdleo6M51 QAbWPiH8zi4CTaKuy1JxXaJzm88y3djNuBa1MXRzELQ== X-Virus-Scanned: Debian amavisd-new at guest.guest Received: from mail.076.ne.jp ([127.0.0.1]) by mail.076.ne.jp (mail.076.ne.jp [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id P-0AA3z0wyZr for ; Tue, 3 Sep 2024 16:29:50 +0900 (JST) Received: from mail.fair.moe (124.110.12.171.ap.gmobb-fix.jp [124.110.12.171]) by mail.076.ne.jp (Postfix) with ESMTPSA id 4WychZ5KPMzW0mJ for ; Tue, 3 Sep 2024 16:29:50 +0900 (JST) Date: Tue, 3 Sep 2024 16:29:50 +0900 From: "lain." To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: X-Location: =?utf-8?B?IkVhcnRoL+WcsOeQgyI=?= X-Operating-System: "OpenBSD" References: 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mtoekklyldxcrunq" Content-Disposition: inline In-Reply-To: Autocrypt: addr=(null); prefer-encrypt=mutual; keydata= mQGNBGHVL30BDAC2g9WjfETVgMHoWqAQdNDzTFEnuIginZzZdx5CpkBwAeQZexW5Eo/9C1anl4F e0d3KeOFfLMBlaTohsfgvlNyOE8iVyWi5b4Op4cvSfUVm7vQvm+axVVDjXA0o6H4cOWp4etxKfb lD8/kO7WbvMxGeu2IyENoUXZR6/mr1Y6TOWkouTzbWFB1vOxMn68UMouuk4fYf6K3E7KavUMUqu ME3nqFjlKtyQBQmvpe4SnPVnjlOgIHTz9ffGV4l07j3QeCetR2h+CgOFgb1SNLdgxDCuDAdh0iF fGrPQP4jA7BNOcNBdUrkzuNAXDK4H8GB+Z3Pxc2+7jmtPWMPvmpCaZw2jPw2gaey3HPbhxvM1jX gPqLNnr3hKEFGkGPcXwpuxU9saoLOOArLACOkIy9G3GtaU26IJYLCMSi2N8M873oyFOShtcarNY lqetrJ/37tPxdVlOizE0ZB6VD+v6iFpUeHh9aGAiaTIYjM/tfMVUBHjtoQUrJfR8ONxdd1OuHZr e8AEQEAAbQh56We5bGx5byY5piOIDxrYW5heWFtYUAwNzYubmUuanA+iQHOBBMBCAA4AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEXqMTFPwNvHspnw/iU5MGhC0WaM0FAmVQVRoACgkQU5M GhC0WaM0atAv7B/9RsNYsjeCbwDSYqN41A7qipucfxdPpabDeqQgeCYuFPzAaCKl1u+HpF2bb9/ euJlml2pOj4jOKbPr0XyzfDDJEQgHCM7H+mg7CgdpWKeMbOodIgJ4I/rg/a6cVUXZijtrCOXURM eAObcvQRTNTtNqePDgcJ20/3vEB8TPJLbO7Va0YQ0qH9gC36sgmQhksG5UMEpBlStnrY9St+9VX wSB2J3exLt6T2SCCmPM0IG3kAgbtSCzT08MfCHe3s3PL4fqW2SuJeW8p17EzrUFuOhTuQs1oOmJ +2vww4w+1TL5Km45KdxosvzcEzLOh0g+9ml7O2fnVtR3jvSzijFJJCcrn5+Di1EyjrhinEcQQ1+ Oh270wW/NtwWSBQ/peZb2iiuD7Ry/6zgYlLuASCoSXkOZWH76+zRDIEEx4XX3B0bey8qPgyEvXo OFIt9CHCOGwbDVKx0LgXxzYx6JzvJB4xlrQ9zMMmet2GIT6JUIALA25P9jgRep4elNMH9SxiYk0 uQGNBGHVL30BDACdui3F1uwOwgZ8y0zsL2c3Qw6kFVW4sp2ql7w9hz3IbSO7kTrRUqvZ7Wn97AB LRr4piml02S/ljtdlU4P3Hq1hrnRwReG3AWQjJByhZms4VU3QWauUbv/pZti5vuuB7BEmP2txPr npfBBJW5DdPnebc+BecnhsJRE7jegt8XpDWixxyAwmDdmz0hhjL/dYgGzAfx3RD3SZ5c0KhqEHX 5oTOND8/ncInK7hWB1zBq3oaPB2sfzDiUL5eBk+SPvsSoz8rBBsGGnrBX/BIGTIzQ6nB1AIqeze Rcz4R0j/g67/2yz2puwYzr+3QjjfkK4p4ZYuG7nd41CQUWxy3lgUz9kCnxWcR50AHAQhhQGPZKy hicGU1JyJUZMxqyTslSkPa6ziiC2FCOJ77hZV2Ow+4y9usWkTo6Xuce3gfAGV6xgDLarl/P2hN+ DCIV4INlBKj70WaQg2ZlaKatGgVcCrbY5X/PbI9nEFMVOpjo6nXXhf/WI1mRH3lXQJGuiawF8Lm PkAEQEAAYkBtgQYAQgAIAIbDBYhBF6jExT8Dbx7KZ8P4lOTBoQtFmjNBQJlUFUiAAoJEFOTBoQt FmjNfbsL/2jYau5JOYIE0+qjeXe/skuUJ6pRrthXGI/ap7id/XVi7P9IZSDrVEsetNzBvR+9fiu pP1nwAaNS9MaNTb7dwdKutRjrj/X2kFj1HCMJJPJIfmQVdrCaA7AnrBMx4YgA2eAg899LN4v/j5 Y1ljoBxxxJ7OVw30uGCysiMgfQKNFKKRiKMqcfyzF2SImhTO0xBvkjamTmupY0MZdgoK0LDI0bQ dTDOsQJa9D9d25DnH8oCNttapFx9NhVA3+1TG9bJF1JukRyYuHyn7m9GP21hpBjBbvgNtLsZT5a 772XAem0Ro5qLT1BUv+R1B+EtffjKYp8Rhy4VBuSUx3e8ELOdIe+ok1XhrnA5xeMVlPwEADO4jp R09BcYQzA6Fjjo9/yGx1n0TEeYBHfLCggBZlgC66J1XNDIjWc2rNiLUCZh/kZAmlGbG2+3tNFlR DgmMeOKxwPO73VbuJbcMwx7sBNu9TzH2DMVLg8OHzWD6KNg8pYrwVugk1xNjvOroSLqN96uA== User-Agent: NeoMutt/20240201 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[076.ne.jp:s=dkim]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fair.moe]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.76.192.0/19, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[076.ne.jp:+] X-Rspamd-Queue-Id: 4Wychm3xqLz4Yd6 --mtoekklyldxcrunq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024=E5=B9=B409=E6=9C=8803=E6=97=A5 00:23, the silly Tomek CEDRO claimed= to have said: > Rust for Linux maintainer steps down in frustration with 'nontechnical > nonsense'. >=20 > Community seems to C Rust more as a burden than a benefit >=20 > https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_do= wn/ >=20 > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Exactly as I predicted. Only a matter of time until a massive hype settles, and a sense of reality returns again. Rust works on Redox, because that OS has been written in Rust from the get go. Rust does not work on Linux or FreeBSD, because those are written in C. It's really that simple! "But Unix was written in Assembly, and got rewritten in C!" Yes, but C is pretty close to Assembly, and the Unix codebase back then was still small, so a rewrite was pretty easy. Good luck rewriting the entire Linux kernel to Rust without committing suicide though. --=20 lain. PGP public key: https://fair.moe/lain.asc --mtoekklyldxcrunq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRjt7VGft6AEgroX7Nt5cCzjCJFhwUCZta66gAKCRBt5cCzjCJF h02uAQCnJfncmqlc0fyONeMm51lvf3STXeRyevbIb5u7Iun+fwEAooS4DMnmmiDm KYZpSpjCDedMDBKx+iHr82UYzTdWsAs= =9+zp -----END PGP SIGNATURE----- --mtoekklyldxcrunq-- From nobody Tue Sep 3 10:57:12 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 4WyjHz0lFJz5Mn3Y for ; Tue, 03 Sep 2024 10:57:19 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyjHy5c5Jz4J7l for ; Tue, 3 Sep 2024 10:57:18 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725361035; x=1725620235; bh=uv7SYOUbaLWPfkiWsRJ5PmTqKcGIYs0LxzvKGHUARfE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=CHOkj3yGVvbp6h0UubbksrQwJv1uDAzRUaJdbul4tJLwtQe8fGYB1PciAwPfQUGiP 3FBlBxDn1QsG0UbAC9YKa9Fb7Eq2nuGGt8PSKDAORQQVOrMmcZ6OyQXzsaq+xon3Hg hM565EJLPI01Xi7LioTa44lSiLzxKlfxtcCWCwLc3p+AlyIx3eQM3T530bMRQj+TAu 2qPokYnG2oVarHHV5zYLqt67/YZqdjuwHW4C0g91wdr8HktPwJRP93BrGFwbMlH/FR Zzc8dfkMAGtZid3tvTDkcyt/A+49jlTf2Cz6ZT/GUHLEH21VSQtXHfMk7E/g6rAV7S ovEPZxytM+9PA== Date: Tue, 03 Sep 2024 10:57:12 +0000 To: "lain." From: fvalasiad Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: In-Reply-To: References: Feedback-ID: 78761413:user:proton X-Pm-Message-ID: ebaed0d8b2e6c3b451343fa9b974cf0aba80a004 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4WyjHy5c5Jz4J7l This is rather pessimistic though, just because a kernel was initially writ= ten in C, means that it won't ever have a chance at another language? I am pulling this out of my *** but C devs seem to be in decline, what's wo= rse, having no devs or having devs that specialize in other languages? Still weird that rust was added to a kernel before C++ though, C++ being al= most a superset of C would have probably helped with its adoption. But people still (also) refer to C++ when they wanna talk about memory bugs= , as if that problem hasn't been solved by RAII for a decade+. Yes, in legacy codebases that used C++ as "C with classes" per its original= name, memory bugs are still found today, but I'd be really interested to s= ee statistics and comparisons on the matter when compared to a modern C++ c= odebase. Again, rust community being more vocal gives the false idea of a thriving d= eveloper community but in reality rust is hard to use and I struggle believ= ing people would choose rust to contribute to FOSS kernels if they find dev= eloping in C and C++ difficult. Source: I made it all up, very happy to see myself proven wrong in the futu= re. Can't deny that I am eager to see where this whole situation is going i= n the times to come. Fotis On Tuesday, September 3rd, 2024 at 10:29 AM, lain. wrote: > On 2024=E5=B9=B409=E6=9C=8803=E6=97=A5 00:23, the silly Tomek CEDRO claim= ed to have said: >=20 > > Rust for Linux maintainer steps down in frustration with 'nontechnical > > nonsense'. > >=20 > > Community seems to C Rust more as a burden than a benefit > >=20 > > https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_= down/ > >=20 > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >=20 >=20 > Exactly as I predicted. > Only a matter of time until a massive hype settles, and a sense of > reality returns again. >=20 > Rust works on Redox, because that OS has been written in Rust from the > get go. > Rust does not work on Linux or FreeBSD, because those are written in C. > It's really that simple! >=20 > "But Unix was written in Assembly, and got rewritten in C!" > Yes, but C is pretty close to Assembly, and the Unix codebase back then > was still small, so a rewrite was pretty easy. > Good luck rewriting the entire Linux kernel to Rust without committing > suicide though. >=20 > -- > lain. > PGP public key: https://fair.moe/lain.asc From nobody Tue Sep 3 11:31:39 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 4Wyk3j36vBz5Mr6x for ; Tue, 03 Sep 2024 11:31:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wyk3j0tmxz4Mdm for ; Tue, 3 Sep 2024 11:31:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 1C4B3892B6; Tue, 03 Sep 2024 11:31:41 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 483BVdax004602; Tue, 3 Sep 2024 11:31:39 GMT (envelope-from phk) Message-Id: <202409031131.483BVdax004602@critter.freebsd.dk> To: fvalasiad cc: "lain." , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) In-reply-to: From: "Poul-Henning Kamp" References: 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: text/plain; charset="UTF-8" Content-ID: <4600.1725363099.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 03 Sep 2024 11:31:39 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4Wyk3j0tmxz4Mdm -------- fvalasiad writes: > This is rather pessimistic though, just because a kernel was initially w= ritten > in C, means that it won't ever have a chance at another language? History is very close to a total confirmation on that hypothesis, but that may not be predictive of the future. All the kernels I know about, which have changed programming language, have amounted to total rewrites, partly because humans were faster at reinterpreting than converting the old source to the new, but mostly because the languages had different and non-compatible calling conventions. DARPAs "Convert C to Rust" call for research is =E2=80=A6 ehh =E2=80=A6 am= bitious? =E2=80=A6 but it may actually make that part of the process less critical. You would of course still end up with a Rust kernel using C ABI, but I can imagine much worse. But first and foremost: There has to be a good enough reason. A very large part of that is convincing people they're not about to detour into a cul-de-sac from which it will very hard to get out[1] When you have been around the blocks for a few decades, you will have noticed that "The New Solution to Everything" is like chicadas: Every 7 or 8 years there is a LOT of noise and it generates a LOT of garbage before it is over. But every so often, one of them succeeds and stick around and it is seldom the obvious one[2]. SqLite vs MySQL - Who ordered that? Outside its "cult" I dont think a majority is yet convinced that Rust is going to be around ten or twenty years from now, whereas I doubt anybody seriously expect we'll get rid of C that fast. The best way to make Rust stick around, is to build a better mousetrap and make a lot of people use it, rather than try to convert people. But personally I wouldn't be at all surprised if ten years from now, Rust will be firefox's MUMPS. Poul-Henning [1] It says a lot about our civilization that there is now an internationally recognized road-sign for "If you are following your GPS: STOP and TURN AROUND", because there is a small Welsh village you can get an 18-wheeler into. [2] Many who knew, will have forgotten, and most are too young to know, but back in the 1980'ies all the smart money were on PROLOG and MODULA-3 as the Object Oriented Languages To Solve All Our Problems. C++, initially called "C with classes", were ridiculed as a futile attempt to keep C relevant in The Century of the Fruitbat. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Tue Sep 3 13:03:20 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 4Wym6G0j5Jz5PTKj for ; Tue, 03 Sep 2024 13:04:06 +0000 (UTC) (envelope-from ske-89@pkmab.se) Received: from mail1.bemta37.messagelabs.com (mail1.bemta37.messagelabs.com [85.158.142.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.bemta37.messagelabs.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wym6D72PVz4ZJD for ; Tue, 3 Sep 2024 13:04:04 +0000 (UTC) (envelope-from ske-89@pkmab.se) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ske-89@pkmab.se designates 85.158.142.113 as permitted sender) smtp.mailfrom=ske-89@pkmab.se X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRWlGSWpSXmKPExsVyYCl7k64D5/U 0g1PXhSy2b/7H6MDoMePTfJYAxijWzLyk/IoE1owZK/+yFKxhruh694CtgfE+UxcjF4eQwHRG iWP3v0E5CxgldvxrZu5i5ORgExCV2Nd9F8wWFjCWWLv1E2MXIweHiIC8xILz9iBhFgFdifvT2 9hAbE6BfImuU7/BbAkBBYkvO+axgti8AoISJ2c+YQGxmQV0JN71PWCGsOUlmrfOZgYZySwgJX GyyRSi3FRiwpTbTCC2kICMxKVFx9ghRgZLvP7eyDKBkX8WkqmzkEydhWTqLISpCxhZVjGaFac WlaUW6VroJRVlpmeU5CZm5uglVukm6qWW6ublF5Vk6BrqJZYX66UWF+sVV+Ym56To5aWWbGIE hm1KcWLYDsbJ+xv1DzFKcjApifLqPrqWJsSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mCN5rjepqQY FFqempFWmYOMIZg0hIcPEoivIpsQGne4oLE3OLMdIjUKUZFKXFeZhaghABIIqM0D64NFreXGG WlhHkZGRgYhHgKUotyM0tQ5V8xinMwKgnzxoNs58nMK4Gb/gpoMRPQ4vVOV0EWlyQipKQamPw WL1E7MzXj/JzP3TKzYw3V74Rvnj1J8UvyD6VdZbFVi30kNZ8cfCyV4vwvopN/id9zp/umd4SO 7l2zfEeBVfXzrFn3BZbc5I487Om10va0fdbU0oXrZ/5Q0UpX/bNTIlxA3euVpuCsxXInn7kJZ yeJiHXOW6luet++uCv2t+FFmRdl/+1dAjqCJ3g9zyv9oFnL58Ek/MI38ZqhwjExH8b9QT0VEy WY+pZLRobJnXfeKKO+7Vly9gzx+fHSk/+9rwnz9W32/LFeQmY6t6fY4W/ndXl27ExcNJP7L0P xCZ/SB4u/TK5+uHiu2nuBw3cXBR6S9vpt7967dPLOby5394suKtlmXte6956/pj7XbSWW4oxE Qy3mouJEAPziRr5WAwAA X-Env-Sender: ske-89@pkmab.se X-Msg-Ref: server-10.tower-725.messagelabs.com!1725368640!29810!1 X-Originating-IP: [192.165.7.130] X-SYMC-ESS-Client-Auth: outbound-route-from=fail X-StarScan-Received: X-StarScan-Version: 9.114.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11340 invoked from network); 3 Sep 2024 13:04:00 -0000 Received: from unknown (HELO PSY-APP020.precio.lan) (192.165.7.130) by server-10.tower-725.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 3 Sep 2024 13:04:00 -0000 Received: from berenice.precio.lan ([172.27.68.201]) by PSY-APP020.precio.lan with Microsoft SMTPSVC(10.0.17763.1697); Tue, 3 Sep 2024 15:03:59 +0200 Received: from pkmab.se by berenice.pkmab.se with uucp id aa12667 for ; Tue, 3 Sep 2024 15:03:59 +0200 (CETDST) From: ske-89@pkmab.se Subject: Re: The Case for Rust (in the base system) To: freebsd-hackers@freebsd.org Date: Tue, 3 Sep 2024 15:03:20 +0200 (CETDST) In-Reply-To: <202409031131.483BVdax004602@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 3, 24 11:31:39 am X-Mailer: ELM [version 2.4 PL23] 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <202409031503.aa12667@berenice.pkmab.se> X-OriginalArrivalTime: 03 Sep 2024 13:03:59.0706 (UTC) FILETIME=[BE01C3A0:01DAFE01] X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.26 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; NEURAL_HAM_SHORT(-0.98)[-0.976]; R_SPF_ALLOW(-0.20)[+ip4:85.158.136.0/21:c]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:16509, ipnet:85.158.142.0/24, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[85.158.142.113:from]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[pkmab.se]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XOIP(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[85.158.142.113:from] X-Rspamd-Queue-Id: 4Wym6D72PVz4ZJD With all this talk about Rust in the OS kernels, can someone explain to me why Rust can't simply produce object files that can be linked into the kernel like any C object file? (If you just avoid calling Rust-specific libraries, just like you don't call the C standard library either from within the kernel.) I haven't worked with Rust, and the introductions to Rust that I have read do not discuss this. /Kristoffer Eriksson From nobody Tue Sep 3 13:33:44 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 4Wymmg0JYmz5PX89 for ; Tue, 03 Sep 2024 13:33:55 +0000 (UTC) (envelope-from me@levitati.ng) Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wymmf1xY5z4h5Q for ; Tue, 3 Sep 2024 13:33:54 +0000 (UTC) (envelope-from me@levitati.ng) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=levitati.ng header.s=purelymail1 header.b=bHRbSQQM; dkim=pass header.d=purelymail.com header.s=purelymail1 header.b=IOLxs6j6; dmarc=pass (policy=reject) header.from=levitati.ng; spf=pass (mx1.freebsd.org: domain of me@levitati.ng designates 34.202.193.197 as permitted sender) smtp.mailfrom=me@levitati.ng DKIM-Signature: a=rsa-sha256; b=bHRbSQQM8X6KhIOf/mNIJF0ersN/njDvTYBxvp3RgonpQuHATWJYAtQ/hOiMFoU9NKY/Rko8nJiECywE67wuOomPm2XSZnJVwdULi6brEGRAb8KlRdQyAgmWTv2B7WyrN8KkthHUmGYgLbruM7aa0e8S8V/LlSa3dmHKmt1UytvK4vCvGWwDQRBFSaSo+RPsCcRKLHE+9oqniY3ZnHlpb/cMZpv/BasMKkJ6rPjFoU1Uc6wxM0Kt2cN8GiCI1oRVXXyc/UWPCEnE4L/zpUFUi31FPMM0/h7IWlzB21bSwYCWhs4pu+AJV6dgqhTxUMnED0LTVn6ILHPLAdE2BHdwsQ==; s=purelymail1; d=levitati.ng; v=1; bh=S2ouTa/82+lZkQKIxz8LNuHnPz4Iu2tnkISW0r2RV04=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=IOLxs6j66hvtUhs6EHDMDJxws4IQsPcOimzLmjUOglBuf33CFf0AeCbXnT0x1TJePM5Kk+FFYj6NJgMa9xLYliD7vdN8V76YbdcK8Wf8cmuezg9FjIP1R5jy2asd8A1us3XjXVMS0u1OVFfqFnretSnUx3pSbhatAq4rnWZrA0ysFetAw8GFGdN43J7kvi7B2623WcIp6MPYkzhLQrp+6OwT0iwkRBQISWnM9aU5Zu2Y/mriierKSb97MnPxu+kpIDFanPIRZazChffYo+EJ/QARn6iYteKBHsUvQohaLcTJgu9wL9Ofk69B2uUjI+Okcq6T4Y6b90R3vZU0GHBtwA==; s=purelymail1; d=purelymail.com; v=1; bh=S2ouTa/82+lZkQKIxz8LNuHnPz4Iu2tnkISW0r2RV04=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 25799:4744:null:purelymail X-Pm-Original-To: freebsd-hackers@freebsd.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -463110252 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Sep 2024 13:33:48 +0000 (UTC) Date: Tue, 03 Sep 2024 15:33:44 +0200 From: me@levitati.ng To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) User-Agent: K-9 Mail for Android In-Reply-To: <202409031503.aa12667@berenice.pkmab.se> References: <202409031503.aa12667@berenice.pkmab.se> Message-ID: <4E4E3807-EE79-4C7A-920A-2927D40D932C@levitati.ng> 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/alternative; boundary=----45840PNZC0JC4RT8PUX6IPHWPS4M9O Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[levitati.ng,reject]; R_DKIM_ALLOW(-0.20)[levitati.ng:s=purelymail1,purelymail.com:s=purelymail1]; R_SPF_ALLOW(-0.20)[+ip4:34.202.193.197]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[me]; ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[levitati.ng:+,purelymail.com:+] X-Rspamd-Queue-Id: 4Wymmf1xY5z4h5Q ------45840PNZC0JC4RT8PUX6IPHWPS4M9O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It can, just pass the --emit=3Dobj flag to rustc=2E Rust also allows you to create functions with the C ABI=2E On September 3, 2024 3:03:20 PM GMT+02:00, ske-89@pkmab=2Ese wrote: >With all this talk about Rust in the OS kernels, can someone >explain to me why Rust can't simply produce object files that >can be linked into the kernel like any C object file? (If you >just avoid calling Rust-specific libraries, just like you don't >call the C standard library either from within the kernel=2E) > >I haven't worked with Rust, and the introductions to Rust that >I have read do not discuss this=2E > >/Kristoffer Eriksson > ------45840PNZC0JC4RT8PUX6IPHWPS4M9O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It can, just pass the --emit=3Do= bj flag to rustc=2E

Rust also allows you to create functions with th= e C ABI=2E


On Sep= tember 3, 2024 3:03:20 PM GMT+02:00, ske-89@pkmab=2Ese wrote:
With all this talk about Rust in t=
he OS kernels, can someone
explain to me why Rust can't simply produce o=
bject files that
can be linked into the kernel like any C object file? (=
If you
just avoid calling Rust-specific libraries, just like you don'tcall the C standard library either from within the kernel=2E)

I ha=
ven't worked with Rust, and the introductions to Rust that
I have read d=
o not discuss this=2E

/Kristoffer Eriksson

------45840PNZC0JC4RT8PUX6IPHWPS4M9O-- From nobody Tue Sep 3 13:36:46 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 4WymrC6zG9z5PXTQ for ; Tue, 03 Sep 2024 13:36:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WymrC5HxGz4kQX for ; Tue, 3 Sep 2024 13:36:59 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-f170.google.com with SMTP id 5614622812f47-3df0c1271c1so3055524b6e.1 for ; Tue, 03 Sep 2024 06:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725370618; x=1725975418; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j40d4jYf9ezuM1EmiTnsQddc7BSVw4WfGn8Qd4gYmts=; b=fZxXwAvUiHO3kK+krN7VYHQDuWSAiwRB0IgsXeauRWs00Vry3Ogh4X8hiP3LbIyUyt 8XAOALHBS8bL961E7yhwp0XhdWoQDxZO5uicf7td8KOmkWAhG6Cwuu8irZvmYeN+YFg7 krdahscIbcIS7NwKin6HdW9idzfWTvtW0+Qi1RFnIND2V1EoPB45ivPv1YSHIGjwuDuC I+Rm5d6xuXd7hD6iIR6rggFIXc0BhEjnxV9WzwUUKit9GWjneEOYZs/T9PdZJUV0QQw0 UbJ8dcdOKzuaTslaBZX1z9d9Aacj1krPp7Vs3wHwt3xiJw0h2c5ufi6Cun3e0FVJ8o7Q MIwQ== X-Gm-Message-State: AOJu0YwEsXqO+Y/xUiaEIohK7cofujZLe7RQ1QDNbpwknH5qEC2YjaN0 PykVJ5bbcN+6SaD4kQgCetobx8kCZWTMXMlrOU7HNg1eTtrnr6s8Vx1IK82jKo/iKWOnw6bvUiV O7f2tpMjMWCLBHJ0Pn84Sc78yp8GRDBKG X-Google-Smtp-Source: AGHT+IGFn2ZnazrX+LIIbmz5GQfVtSefo64TDBmaKyHw9BgfKmIHwg6otlse/xfndf1fXdGemo2PmO2s4szIG+o3hAc= X-Received: by 2002:a05:6808:4496:b0:3e0:544:ef78 with SMTP id 5614622812f47-3e00544f0c4mr8232987b6e.48.1725370618410; Tue, 03 Sep 2024 06:36:58 -0700 (PDT) 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 References: <202409031131.483BVdax004602@critter.freebsd.dk> <202409031503.aa12667@berenice.pkmab.se> In-Reply-To: <202409031503.aa12667@berenice.pkmab.se> From: Alan Somers Date: Tue, 3 Sep 2024 07:36:46 -0600 Message-ID: Subject: Re: The Case for Rust (in the base system) To: ske-89@pkmab.se Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WymrC5HxGz4kQX On Tue, Sep 3, 2024 at 7:04=E2=80=AFAM wrote: > > With all this talk about Rust in the OS kernels, can someone > explain to me why Rust can't simply produce object files that > can be linked into the kernel like any C object file? (If you > just avoid calling Rust-specific libraries, just like you don't > call the C standard library either from within the kernel.) > > I haven't worked with Rust, and the introductions to Rust that > I have read do not discuss this. > > /Kristoffer Eriksson Actually, it can. You have to take some precautions, of course: many 3rd party libraries are off limits, as is much of the standard library. You must disable the usual panic mechanism. You need to declare that your module's public API uses the C calling convention. Probably the biggest limitation is that you can't use the standard memory allocator. But you absolutely can do it. For example: https://github.com/spookyvision/hello-freebsd-rust . One of the most interesting features of Rust is #![no_std] . If you declare that in your library, then none of the standard library will be available. However, there are a dozen or so primitives like memory allocation and panic handling. If you implement some of those, then any parts of the standard library that depend on them will be available again. And if you implement all of them, then you can use virtually the entire standard library. It's a nice bridge between the regular world and the embedded world. -Alan From nobody Tue Sep 3 15:32:00 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 4WyqP82sNyz5TR9s for ; Tue, 03 Sep 2024 15:32:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyqP66vqjz53cv for ; Tue, 3 Sep 2024 15:32:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 3DD35892B6 for ; Tue, 03 Sep 2024 15:32:01 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 483FW0If007252; Tue, 3 Sep 2024 15:32:00 GMT (envelope-from phk) Message-Id: <202409031532.483FW0If007252@critter.freebsd.dk> To: freebsd-hackers@freebsd.org Subject: It's not Rust, it's FreeBSD (and LLVM) From: "Poul-Henning Kamp" 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: text/plain; charset="us-ascii" Content-ID: <7250.1725377520.1@critter.freebsd.dk> Date: Tue, 03 Sep 2024 15:32:00 +0000 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[phk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WyqP66vqjz53cv 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. ('make world' celebrated 30 years last month! See: 3540f0e14a8) The only compiler we had source code for was GCC. We would have preferred a different license, but we had no choice at the time. There were people who, reasonably, thought that X11 was also part of a "complete UNIX system", but the reality of 1.2MB "3D-printed save icons" made that a total non-starter, and therefore the ports collection is FreeBSD's barely younger twin. The source tree became our citadel: "FreeBSD is src". If something was not in src, it was not FreeBSD. Buildworld or bust. The fight at the gate was fierce at times. Delivering a single consistent userland with the kernel has stood us well for three decades, and we should stick with that. But the world has changed, and we all know it, which is why ports, pkg, freebsd-update and pkgbase exist. A FreeBSD system with no installed ports is a rarity today. Not even a FreeBSD developers test-machine can avoid git-lite, but such machines do exist, typically in embedded applications. But a FreeBSD system recompiling itself from source is even rarer. 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. 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)" As part of the migration, we yank LLVM out of the src. 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) "pkg upgrade" also upgrade kernel and userland packages - Welcome to the century of the fruitbat. The "normal install images will also contain: The src package(s) the source code built into kernel and userland packages The toolchain package(s) the package used to build the kernel and userland packages The ports package(s) the ports tree used to build the toolchain package(s) All distribution files necessary to build the toolchain package(s) (The "toolchain-llvm" (meta-)port may have to be a short-cut, to not have the llvm port drag in everything and the kitchen-sink, which would be /precisely/ the same as the llvm which lives in src today.) This distribution format is neither more nor less perfect with respect to reproducible builds and "Reflections on trusting trust" than what we have today. And yes, we have ports written in Rust, why do you ask? Poul-Henning PS: I overdosed on release work 25+ years ago, and have not been paying them much attention since, but if this is what the pkgbase crew has been pushing for more than a decade, we all owe them an apology. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Sep 3 16:37:54 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 4WyrsC0Kd6z5TXvF for ; Tue, 03 Sep 2024 16:38:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4WyrsB71yBz41vt; Tue, 3 Sep 2024 16:38:06 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725381486; 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=GRQuib22Wr22UiXEWbuoU1GpqzqYzwc/vSRInqnI7fo=; b=LAB0dl+KaIOYo7BhkPeBdPaNRlQKJBuV+zkX7xcozvp4cwYnTJpnXm/mFGNXosYjCmJjG6 bbcv5a8Bkf+1YoLe8X2hshtfwzVt/2vJV7zZDBXfDedupouoI9zhjJByv5Aklwp6zc3oMT 2S41As6oL4lhBovQFu7IJuDzCqWYyadAWIkLl2K4I6bcHwarlruOQztyeN5KWqWV68XKdc t5PrzpeZ9YF8oAwqU1m7HXfIvd1z+9fXN9vPf1Ivm21Uhba0WsjIe6etibEQTZrGPy9jnP e1h7PejLyg58fP4MjVd5Icg3K4AqHJhgrQmGD8NY+9QlHsRCWXt3/gw6POWFdg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725381486; a=rsa-sha256; cv=none; b=qzosZgeqNhGWH8ZYovaWwkrle/YoaGn9AA/p3OtLk5Cu2ITwlcRSytWRIvGR5Lrxn0bJeE uEKgkqMglQSO1RfpGsD0Rj1pmJF7iIn5FJICEmFeMeJ0Qt7FgREZdOkKe70x5UQSsLtK5M IsBhSR3Tza8BYCSklCnbsWeEWjgFukNaoV2bLQVWvmnwLVsyjsT/rZJkmZTJVacqsMsGhv /GtGtJa38Xp7jKaIZoI5EY46ybfQUpExZ3wNczYndTxpXmZQMwQX3tr74uBIvhdrKBe6kt zwh2TE12BKi6x8/NLdlyS35abx0Gda+27ZACBCwjPA5IEq0/7t/riDB1I9aq2w== 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=1725381486; 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=GRQuib22Wr22UiXEWbuoU1GpqzqYzwc/vSRInqnI7fo=; b=lXssNs9W7wPc6am8ez+ADlbgiihIHQuUR02l+42A+xV/2uax33iTGIjIm9Mw+4kNpGnyMx CyhfakhXXKzNFa0nIoAgS+J95xLP+Eows6MGkna9QAt7Xk5YCyidaahs7bjBylIyvul9d8 8RviGR/YjQQyW/Xjnu2AVIsx97yRhyOLGylknfyrF0VO8LbCk3wJj87BFJXXvK0PMsv01s I3ipkMZ6VaZEYSMvRZrLc61KlWIaPomx1L7lnvAGT6wSZfxYhE14p4YKW30wle7l8MqFi2 hCo3ZQ/YHm1xnDJGnZ/jc4PVPksy788pWHVeMNfj3K4epafTewA+Yng/7QLppg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WyrsB6R3Xz19kD; Tue, 3 Sep 2024 16:38:06 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 40F9C50D9; Tue, 03 Sep 2024 17:38:06 +0100 (BST) From: David Chisnall Message-Id: <8981BC7B-6487-4FE7-9965-23B911367D2B@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 3 Sep 2024 17:37:54 +0100 In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> Cc: FreeBSD Hackers To: Poul-Henning Kamp References: <202409031532.483FW0If007252@critter.freebsd.dk> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 3 Sep 2024, at 16:32, Poul-Henning Kamp wrote: >=20 > 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. It=E2=80=99s worse than that because, although we import the *source = code* verbatim (mostly, occasionally with a few back-ported or = not-yet-upstreamed fixes), we don=E2=80=99t import the *build system*. = We replicate a subset of what the upstream build system can do. > The only reason we do that, is because we stil have that outdated > "FreeBSD is src" emotional hangup. I don=E2=80=99t think this is quite the emotional hangup I have. It = doesn=E2=80=99t matter at all to me where the code lives. If we ripped = LLVM out of the src tree and built a package using the code that=E2=80=99s= currently in ports with CMake + Ninja + pkg, and made it part of the = core distribution, it would still be =E2=80=98FreeBSD=E2=80=99, because = it=E2=80=99s the POLA boundary. If I learn how something works in the bit of the system that is FreeBSD, = I don=E2=80=99t have to relearn it unless there=E2=80=99s a compelling = reason why the old abstractions can no longer reflect the new world = (around 9ish, there was a change in how WiFi was configured, for = example, but wired Ethernet for IPv4 is still configured the way I = learned in 4.x, because it got faster but not qualitatively different). Even though cc and c++ were gcc in 4.x and are clang now, I still invoke = them the same way. They now support newer things (C++23 and C2x, not = just C++98 and C99, hurray!), but the older things still mostly work the = same way. Similarly, anything that=E2=80=99s a library in the bit that is FreeBSD = is either marked as private, or has a stable ABI throughout (and, = ideally, beyond) a release series (LLVM does not have this property, = which is why we ship Clang, lld, lldb, and so on, as tools that use = LLVM, we don=E2=80=99t ship *LLVM* in the base system). If we ripped = contrib out of src and kept the same guarantee from the git clones of = the upstream things, that would be fine. I expect that FreeBSD 15.5=E2=80=99s C/C++ compiler will compile any = C/C++ compilation unit that FreeBSD 15.0=E2=80=99s does (with a = get-out-of-jail-free card for things that rely on undefined behaviour). = If it doesn=E2=80=99t, I expect that this is something that the project = will treat as a bug and work with upstream to fix it. =20 In contrast, if I install some compiler from the ports tree, I expect = different (not necessarily weaker) guarantees. I expect that the = version from packages-built-from-ports have the same guarantees as the = upstream project. This may be a 6-monthly release cycle with support = for things that fixed any deprecation warnings from the last two = releases. It may be a never-breaks-backwards-compatibility-ever = guarantee, depending on the program / library. For Rust in FreeBSD, I would expect one of two things: Option 1: FreeBSD rustc is not binary that we supported binary for = building anything outside of the base system. Rust code in the base = system may need updates to the compiler to be MFC=E2=80=99d at the same = time (again, I have no opinions about where the code *lives*, MFC may be = a submodule update, an update to a ports-like recipe, or a full code = import). We have a blessed set of packages. Option 2: FreeBSD rustc is supported for third-party things, minor = versions may bring in new ones, but within a release series we expect = full backwards compatibility with the exception of things that fix = soundness issues in the type checker (if cve-rs stops working within a = major release series, that=E2=80=99s a feature not a bug). I believe Rust now has strong enough guarantees for Option 2 to be = feasible (I=E2=80=99m not 100% sure). But that neither, to me, requires = bringing rustc into contrib. It requires providing a way of building an = atomic snapshot that is the things that we define as FreeBSD N, and = guarantees of compatibility between FreeBSD N.0 to N.M. Note that some of the stability guarantees are already quite complicated = and I think merit longer discussions. For example, I=E2=80=99m told = that some kernel modules broke across the 13.x series (in particular, = VirtualBox ones) and needed recompiling. My understanding was that we = went and added padding to data structures before a .0 series to prevent = this. If this isn=E2=80=99t the case, then we need to be more explicit = about *which* KBIs are stable / unstable across a major release. The = existence of LinuxKPI also complicates these discussions, because = LinuxKPI is a compat layer that tracks an unstable target (whatever = Linux is doing this week) and so, by definition, *cannot* have the same = stability guarantees as the base system, but it is necessary for = supporting most modern GPUs. If anything, some of these stability guarantees are *more* valuable now = than they have been for much of the last couple of decades. The Linux = world is struggling with containers because containers incorporate a = userland from some distro, but inherit the kernel from the host. Can = you run an Ubuntu 20.04 and 22.04 container on your host? Maybe. = FreeBSD is in a great position to ship a family of container base images = for major releases and get all of the benefits that container platforms = provide in terms of sharing from common images (two containers with the = same set of base layers can share disk and buffer cache space for the = common bits), while still providing the benefits of = latest-version-of-third-party-things via ports / packages. Being able = to have a single supported version of a FreeBSD 15 base layer with the = core libraries (and a set of additional layers that bring in = progressively more things) and expect people to just point at = freebsd15:latest as the base and rebuild their containers to pick up the = latest bits is great, but depends on the compatibility guarantees that = FreeBSD embodies (ABI for libraries, CLI for tools). =20 David --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 3 Sep = 2024, at 16:32, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote:

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.

It=E2=80=99s = worse than that because, although we import the *source code* verbatim = (mostly, occasionally with a few back-ported or not-yet-upstreamed = fixes), we don=E2=80=99t import the *build system*.  We replicate a = subset of what the upstream build system can = do.

 The only reason we do = that, is because we stil have that = outdated
"FreeBSD is src" emotional = hangup.

I don=E2=80=99t think = this is quite the emotional hangup I have.  It doesn=E2=80=99t = matter at all to me where the code lives.  If we ripped LLVM out of = the src tree and built a package using the code that=E2=80=99s currently = in ports with CMake + Ninja + pkg, and made it part of the core = distribution, it would still be =E2=80=98FreeBSD=E2=80=99, because = it=E2=80=99s the POLA boundary.

If I learn how = something works in the bit of the system that is FreeBSD, I don=E2=80=99t = have to relearn it unless there=E2=80=99s a compelling reason why the = old abstractions can no longer reflect the new world (around 9ish, there = was a change in how WiFi was configured, for example, but wired Ethernet = for IPv4 is still configured the way I learned in 4.x, because it got = faster but not qualitatively different).

Even = though cc and c++ were gcc in 4.x and are clang now, I still invoke them = the same way.  They now support newer things (C++23 and C2x, not = just C++98 and C99, hurray!), but the older things still mostly work the = same way.

Similarly, anything that=E2=80=99s a = library in the bit that is FreeBSD is either marked as private, or has a = stable ABI throughout (and, ideally, beyond) a release series (LLVM does = not have this property, which is why we ship Clang, lld, lldb, and so = on, as tools that use LLVM, we don=E2=80=99t ship *LLVM* in the base = system).  If we ripped contrib out of src and kept the same = guarantee from the git clones of the upstream things, that would be = fine.

I expect that FreeBSD 15.5=E2=80=99s = C/C++ compiler will compile any C/C++ compilation unit that FreeBSD = 15.0=E2=80=99s does (with a get-out-of-jail-free card for things that = rely on undefined behaviour).  If it doesn=E2=80=99t, I expect that = this is something that the project will treat as a bug and work with = upstream to fix it.  

In contrast, if I = install some compiler from the ports tree, I expect different (not = necessarily weaker) guarantees.  I expect that the version from = packages-built-from-ports have the same guarantees as the upstream = project.  This may be a 6-monthly release cycle with support for = things that fixed any deprecation warnings from the last two releases. =  It may be a never-breaks-backwards-compatibility-ever guarantee, = depending on the program / library.

For Rust in = FreeBSD, I would expect one of two = things:

Option 1: FreeBSD rustc is not binary = that we supported binary for building anything outside of the base = system.  Rust code in the base system may need updates to the = compiler to be MFC=E2=80=99d at the same time (again, I have no opinions = about where the code *lives*, MFC may be a submodule update, an update = to a ports-like recipe, or a full code import).  We have a blessed = set of packages.

Option 2: FreeBSD rustc is = supported for third-party things, minor versions may bring in new ones, = but within a release series we expect full backwards compatibility with = the exception of things that fix soundness issues in the type checker = (if cve-rs stops working within a major release series, that=E2=80=99s a = feature not a bug).

I believe Rust now has = strong enough guarantees for Option 2 to be feasible (I=E2=80=99m not = 100% sure).  But that neither, to me, requires bringing rustc into = contrib.  It requires providing a way of building an atomic = snapshot that is the things that we define as FreeBSD N, and guarantees = of compatibility between FreeBSD N.0 to = N.M.

Note that some of the stability guarantees = are already quite complicated and I think merit longer discussions. =  For example, I=E2=80=99m told that some kernel modules broke = across the 13.x series (in particular, VirtualBox ones) and needed = recompiling.  My understanding was that we went and added padding = to data structures before a .0 series to prevent this.  If this = isn=E2=80=99t the case, then we need to be more explicit about *which* = KBIs are stable / unstable across a major release.  The existence = of LinuxKPI also complicates these discussions, because LinuxKPI is a = compat layer that tracks an unstable target (whatever Linux is doing = this week) and so, by definition, *cannot* have the same stability = guarantees as the base system, but it is necessary for supporting most = modern GPUs.

If anything, some of these = stability guarantees are *more* valuable now than they have been for = much of the last couple of decades.  The Linux world is struggling = with containers because containers incorporate a userland from some = distro, but inherit the kernel from the host.  Can you run an = Ubuntu 20.04 and 22.04 container on your host?  Maybe. =  FreeBSD is in a great position to ship a family of container base = images for major releases and get all of the benefits that container = platforms provide in terms of sharing from common images (two containers = with the same set of base layers can share disk and buffer cache space = for the common bits), while still providing the benefits of = latest-version-of-third-party-things via ports / packages.  Being = able to have a single supported version of a FreeBSD 15 base layer with = the core libraries (and a set of additional layers that bring in = progressively more things) and expect people to just point at = freebsd15:latest as the base and rebuild their containers to pick up the = latest bits is great, but depends on the compatibility guarantees that = FreeBSD embodies (ABI for libraries, CLI for tools). =  

David

= --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7-- From nobody Tue Sep 3 16:50:34 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 4Wys7c1JVZz5TYnl for ; Tue, 03 Sep 2024 16:50:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wys7b71gLz44Z2; Tue, 3 Sep 2024 16:50:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 75D7F8943A; Tue, 03 Sep 2024 16:50:34 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 483GoY0V008318; Tue, 3 Sep 2024 16:50:34 GMT (envelope-from phk) Message-Id: <202409031650.483GoY0V008318@critter.freebsd.dk> To: David Chisnall cc: FreeBSD Hackers Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: <8981BC7B-6487-4FE7-9965-23B911367D2B@FreeBSD.org> From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@critter.freebsd.dk> <8981BC7B-6487-4FE7-9965-23B911367D2B@FreeBSD.org> 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: text/plain; charset="us-ascii" Content-ID: <8316.1725382234.1@critter.freebsd.dk> Date: Tue, 03 Sep 2024 16:50:34 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4Wys7b71gLz44Z2 -------- David Chisnall writes: > In contrast, if I install some compiler from the ports tree, I expect > different (not necessarily weaker) guarantees. Also if that package is called "the-blessed-freebsd-toolchain-and-compiler" ? My suggestion was not that you could install ny compiler from port and expect it to compile FreeBSD src, there will be be one (or more?) (possibly arch dependent) blessed toolchain packages, for which we give the same guarantee as we give the "src" package. > Option 1: FreeBSD rustc is not binary that we supported binary for > building anything outside of the base system. What is this "base system" you talk about ? Does it include git-lite ? bash ? emacs ? For all purposes and intents, we ship something we call "userland" and it is not enough for anybody, but it is enough to build what they need. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Sep 3 17:50:30 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 4WytTG5BJpz5TgTR for ; Tue, 03 Sep 2024 17:50:58 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WytTG3Snnz4Gbb for ; Tue, 3 Sep 2024 17:50:58 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-846d1ba933eso518202241.2 for ; Tue, 03 Sep 2024 10:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725385857; x=1725990657; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9tXZL+CrPidikBcLD1SECG3ZDIm+vUAtVUA52XAJoc0=; b=E9GPbgQI0NR1uH0A6cmDFTw+OpwH/jyHHv3Oueg7EucEaEm7TBDHyPCLi8H2m/vRX/ +gE6ZeZEBLEqzjcpJR5FYXlZbxf5JqM8iaS+9Bor1NsMbrEL00lfrAPf47065ccLhDzP F4g1FAtAAuMShj9qnRwRMrMwzLPO28WLSrxuEZLPmvjHfZ8C4hqWzqZH5Nhj0jZeuIXz auNOKAA913JTreSzF4+C57bjDKwGORK4hnDAGxIRJSJBibnATq+nl2qxvjmveidREZ3C yHBmmiFBcLnxYBKe027apRIEDSGfqVgAH5IHMi/hGgW5UsQ7YXEhjpQ147zEcL8fLoYf xCSw== X-Gm-Message-State: AOJu0YzWRW6UnYo/IIo5EiAI4X9vFcbt68tkFhonvTf1qV1rSl3fE9k1 t0XuOO7otlviH2UaJdqIfJyEjb5ObBluoH8X64TGJoAy+shzVj6JnRSdnov4 X-Google-Smtp-Source: AGHT+IHCloRRkI8ugwx3NaJUpCcRxf/4FVEOle+KsiC/K5P7tFMKViqSelBV8rBJmddTVuOm7zt0Bg== X-Received: by 2002:a05:6102:3584:b0:492:a39c:57d7 with SMTP id ada2fe7eead31-49a77934360mr8922584137.4.1725385857375; Tue, 03 Sep 2024 10:50:57 -0700 (PDT) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com. [209.85.217.53]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-846db9e78dbsm674029241.5.2024.09.03.10.50.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Sep 2024 10:50:57 -0700 (PDT) Received: by mail-vs1-f53.google.com with SMTP id ada2fe7eead31-498dbd7dc89so1539582137.1 for ; Tue, 03 Sep 2024 10:50:56 -0700 (PDT) X-Received: by 2002:a05:6102:38c6:b0:48f:e7f2:b14 with SMTP id ada2fe7eead31-49a77a3deb2mr10582416137.26.1725385856622; Tue, 03 Sep 2024 10:50:56 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> From: Gleb Popov Date: Tue, 3 Sep 2024 20:50:30 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WytTG3Snnz4Gbb On Tue, Sep 3, 2024 at 6:32=E2=80=AFPM Poul-Henning Kamp wrote: > > The only answer I can think of > ------------------------------ > > "FreeBSD is ports (some of those ports contain the kernel and userland)" A port is a build recipe for something. FreeBSD can't be a collection of recipes, it is also the code itself. FreeBSD Ports is a meta-buildsystem, designed to pull from various sources and build using different underlying buildsystems. Under this angle I can't agree with the "FreeBSD is ports" definition. From nobody Tue Sep 3 18:10:33 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 4Wytw61B2Xz5ThtV for ; Tue, 03 Sep 2024 18:10:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wytw56Z3Gz4K2K for ; Tue, 3 Sep 2024 18:10:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2d5f5d8cc01so3841151a91.0 for ; Tue, 03 Sep 2024 11:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725387044; x=1725991844; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9GQ9sYmq23Z6/SHuDQn2u2tbIwbJeOXi5ZKWAOTHgbs=; b=Zgzyfj6l0uPtgFPN3kBrc9ogos0+E8k0zKWwjRj81Jku3iLf0xYDKfZg+g5mAAbBV/ eYPp410OiJua5ssWRnPVvAYM1wyqKUXnnqWWm3AewwY33h6IaVuQOuEfa8DQRq3uHomz eBSsOh+8i28cYhcHpV1rw+baQNXDvpRmS9+ds42HWp8W/N6RxLm+FVs/Btzipu3Ns/sV 9Uwd3iDiSqbB628K7gQnCPgkyaQDOZmFuUOqRqtyCJjcJCsRsfM74EXpaWG3v+npAGx5 EO76VinUmR15C5hh4UK/PbhC/u/FVWUddLSbftsPNXVu9sdycPGxJjGVjk3acTeZcVkR /LAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725387044; x=1725991844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9GQ9sYmq23Z6/SHuDQn2u2tbIwbJeOXi5ZKWAOTHgbs=; b=RAy3C1/kUTUqF5luPRClYui5ZcjydBmxlUI46ey/+tBe+CksbPGIVB+fIwDmWfOL7E Sb5C6Ue1cexN9a/U+oMI46zHZR3IznMYkstOsLAkr4I07eO6v24lwot3/z9D2lkdOdDW ntA/W3RLDyHUgReCaPzGRaB50mpUBQYsiM0/khfvFmPrCjBeeCFqGQ5EUruXFmt4zzSD ACAOfhd5hiLw+69hW5GQQBTrzL8nSx0QZu0RnSQaUxbn+ZDRin/Eblh727TBs6vO4SkB ragQenucRpB4oDwhDAfhTnx+qaOKl3+UrJQQpDMf8aTfie1RKzMArYLmxLvAncOC25Oi 11lA== X-Gm-Message-State: AOJu0YxSmuZtrKzYOyN7fMiSC9enXlVUFTM04nGifmLREGEw6BYL5/Qa kmgSjX6R9pNF2REX46jyaXW2kIc8YsiiDZx+pa3NuWMjvGtRm0sZsLqhhTOMIfcbgKBjoLFSinN hMYV4jKKYFRYCii1jJ+OBUNXOwPBia5981jMuSVfdqVQRS6Po X-Google-Smtp-Source: AGHT+IHjS+f6YhqzYkHdnBpekv4imaETiCeXsk9oo2Sw6dVIHAA6GUol8cizMyywOZOf2qCQUs6vykcQZR4rJwfYz2E= X-Received: by 2002:a17:90a:4e0f:b0:2d8:73ba:9444 with SMTP id 98e67ed59e1d1-2d873ba9619mr22925137a91.5.1725387044505; Tue, 03 Sep 2024 11:10:44 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> From: Warner Losh Date: Tue, 3 Sep 2024 12:10:33 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e36bc606213af9c5" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wytw56Z3Gz4K2K --000000000000e36bc606213af9c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp wrote: > As part of the migration, we yank LLVM out of the src. > > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. > > And yes, we have ports written in Rust, why do you ask? > pkgbase is the path forward. It is the future. We are better off putting all our horses behind that effort so we can make it the default install in 15.0. Once we have that, this whole debate becomes moot, for the most part. Userland in rust can compete with userland in C. And with go, python, etc for whatever does the job the best. If rust is so much better, then people will use it, otherwise they will use the C version. It doesn't become moot for the kernel, but the kernel is much harder. The crux of the issue is that adding Rust bindings double our work to improve and evolve the system: it has to be done for C and for Rust and we have to make sure work done in one doesn't break the other. When you strip off the drama from the Linux dust-up over this, that's one of the fundamental issues that the Linux kernel developers are trying to get answers to and failing. Warner --000000000000e36bc606213af9c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 3, 2024 at 9:32=E2=80=AFA= M Poul-Henning Kamp <phk@phk.freeb= sd.dk> wrote:
As part of the migration, we yank LLVM out of the src.
=C2=A0
"p= kg upgrade" also upgrade kernel and userland packages - Welcome to
the century of the fruitbat.
=C2=A0
And yes, we have ports written in Rust, why do you ask?

pkgbase is the path forward. It is the future. We are bett= er off putting all our
horses=C2=A0behind that effort so we can m= ake it the default install in 15.0.

Once we have t= hat, this whole debate becomes moot, for the most part.
Userland = in rust can compete with userland in C. And with go, python, etc
= for whatever does the job the best. If rust is so much better, then people<= /div>
will use it, otherwise they will use the C version.
It doesn't become moot for the kernel, but the kernel is mu= ch=C2=A0harder. The crux of the issue
is that adding Rust binding= s double our work to improve and evolve the system: it has
to be = done for C and for Rust and we have to make sure work done in one doesn'= ;t break
the other. When you strip off the drama from the Linux d= ust-up over this, that's one of
the fundamental issues that t= he Linux kernel developers are trying to get answers to and
faili= ng.

Warner
--000000000000e36bc606213af9c5-- From nobody Tue Sep 3 18:18:06 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 4Wyv4r4Jd2z5Tjn0 for ; Tue, 03 Sep 2024 18:18:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wyv4q6Dnjz4N4S for ; Tue, 3 Sep 2024 18:18:19 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3df0dc53ec1so3317332b6e.1 for ; Tue, 03 Sep 2024 11:18:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725387499; x=1725992299; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FukBVfAlu/tnXEIMaz1UL7JXh4WLI7fWjEBlhZJDpWQ=; b=LGPCwJ/fFfFmua/uci8NN4aFFtxf8aXHg9g9VfUkgXGi4hy6l3H3p8P7oaqMdmjeE7 w6OZmW/R/3nUij2W601bCM0A7s+q4+I/AimLv1Kl6B+ZLdi1VHE/h8wYJYrCBzMcYNjY R3OjH4sqDo+O684EuibwkrGL1G9+bW5mF097/rHeJEFZJTa3M2Ie5jEDqSocS3c0l7Ke e3Er0+nYBnGXdycu/xSbDl6e3ChEo1euSdc0zsDwfSglUfYafFjxgdaDIDntIOakx4sM XM9UuO7HnyOvrxPIgupA8/spNn7CGim3lh9wMWTQq3T0UW89MeMHOYxiAYGUC9ueWI5j yf8w== X-Forwarded-Encrypted: i=1; AJvYcCU8rKxctbz9dGi3PDhHKI1YNjJdrVunqpQmxvkY0S5x9IwnjO7avam6J8MzfAS/cgJwf8hi6pzrX7Dh0qgDzkk=@freebsd.org X-Gm-Message-State: AOJu0YyTiUnnb8Zb/mkRcO3wm97TqB+P/RoE8d3NVuJjbfhQX/98mONn Gia3qQ8aIw9nwuKW92W2nR4/e8cYVbYo0yXVf8UVuAAHw8/fsjLQLMaAN7823ZfC7oOaiTwGuFG 9xkIiFBUjjG7jTQmDfoPudul49hon/Q== X-Google-Smtp-Source: AGHT+IGEZvTuALcYWtbdYRpQ1CO3ZNQ+taX1YqZaOvJn5RhYEmZv5csTno844XSVht5xP3apZLuyryq9TJHOr3qO7p8= X-Received: by 2002:a05:6808:1309:b0:3da:ab89:a7d2 with SMTP id 5614622812f47-3df1d6298aamr13450168b6e.21.1725387498572; Tue, 03 Sep 2024 11:18:18 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> In-Reply-To: From: Alan Somers Date: Tue, 3 Sep 2024 12:18:06 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Warner Losh Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Wyv4q6Dnjz4N4S On Tue, Sep 3, 2024 at 12:10=E2=80=AFPM Warner Losh wrote: > > > > On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp wrote: >> >> As part of the migration, we yank LLVM out of the src. > > >> >> "pkg upgrade" also upgrade kernel and userland packages - Welcome to >> the century of the fruitbat. > > >> >> And yes, we have ports written in Rust, why do you ask? > > > pkgbase is the path forward. It is the future. We are better off putting = all our > horses behind that effort so we can make it the default install in 15.0. > > Once we have that, this whole debate becomes moot, for the most part. > Userland in rust can compete with userland in C. And with go, python, etc > for whatever does the job the best. If rust is so much better, then peopl= e > will use it, otherwise they will use the C version. How will pkgbase handle the private interface problem? For example, libifconfig and the /dev/cam/ctl ioctls are both unstable. A port that uses one of those and is built for FreeBSD 14.0 won't necessarily work for 14.1. As long as those interfaces' consumers are all within src there's no problem, but if they move to ports then they'll need to be rebuilt everytime the libifconfig or kernel port, respectively, gets rebuilt. From nobody Tue Sep 3 18:25:19 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 4WyvF86bR7z5TkJP for ; Tue, 03 Sep 2024 18:25:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyvF8436Tz4P9j for ; Tue, 3 Sep 2024 18:25:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-7cd8afc9ff3so4497048a12.0 for ; Tue, 03 Sep 2024 11:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725387931; x=1725992731; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Pc+6KUPpLBaAUsiBM7MelY6IvznWV7Tw5pFuT+geQww=; b=IzAaz5nawodzli6iXZ/CcZFmXhtWx4jO3VQ6yvh6EcixbLXbtXRqHxn5PSwYS6/eLd 6VfBwyqiZ4RWW3l3j6HD0i5lGHkJKzPzvYWro6TX1v11x3/3e4wMfhj6R6IvAmNDazDG L9zKJSYi7JJOdgIIfEfnQQbSVZvqbfG72EwkcehdmBUzTaqs2HdmaqasIR0dEwboBH3S iA7JJlH9hQuGUi3uSA/tCx+1EhasK7ih/rizvETDfpSxKzCJVLMDzUYHcc5tMBFRy/r5 fzNIbrLKjqZfj5urj+PPU7+yl2VzC31BY4ek+wC606nU4m+fE+X5PMsAvR/hjfkuLIT0 u+0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725387931; x=1725992731; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Pc+6KUPpLBaAUsiBM7MelY6IvznWV7Tw5pFuT+geQww=; b=N5M+IjT/O4is4+mDZQOr0WESyqp6lXNlWWKlRUCiHfy7yHM702d8UqVwuTOrzCbJD+ sCq2BldN61pA46nONDmNCPxlT3XXDk7ZXrlU0jPrsV/hFGIBJJwgHnIXXb2sMZ8s9BgU rJzUWZmuBhf0i/TW1Nhl5/Z/TLywsn3HhqXBzbi86eZiO+8f/VTYmMXD71hg7KXwZSMa 3RkH4J9xqwn8DQ2XsilD/SABydNghWM14b2GSjLSnCqNIECnbcZT+KB9pTL58sAaxQA8 3sL6CX0ci3n73nN5RPle92g4mSK3cseypNWy1/FdWitngwfdr+1rAkdLAwkoITsrGEAA Yg0Q== X-Forwarded-Encrypted: i=1; AJvYcCVR+c6gDggGoFWgme1I1YEK0oGwd1HJN/YYrB5dIK7BqUgoWmYBLykU5ZkaXgEMeOWejxvUgsNGF5z9vVW030s=@freebsd.org X-Gm-Message-State: AOJu0YwoCZqWi3sTnTOdGkebe9L7k3wirsC3cGLEzacCQkWyULjfpU65 Q2G7cVhqohStQHUt5+boO7pLLVx5wXqLXdVEcBBuBjB534dMXZpRoCFSr96E1gc0z6BfzoD3C8e hcW4WbnRYwyKq5Rm3K+bvrmnokmaa8+6qroM5Rg== X-Google-Smtp-Source: AGHT+IF/r7PztvZTlvIb61erWtjWm/iWxJMJqKLMuNELEBxfT8pzRiJhouaqvbutvXRwR8TWsMrUVdXddXUbcoFN0I4= X-Received: by 2002:a17:90a:4e0f:b0:2d8:73ba:9444 with SMTP id 98e67ed59e1d1-2d873ba9619mr22992907a91.5.1725387930899; Tue, 03 Sep 2024 11:25:30 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Tue, 3 Sep 2024 12:25:19 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Alan Somers Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b8aed506213b2e97" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WyvF8436Tz4P9j --000000000000b8aed506213b2e97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 12:18=E2=80=AFPM Alan Somers w= rote: > On Tue, Sep 3, 2024 at 12:10=E2=80=AFPM Warner Losh wrot= e: > > > > > > > > On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp > wrote: > >> > >> As part of the migration, we yank LLVM out of the src. > > > > > >> > >> "pkg upgrade" also upgrade kernel and userland packages - Welcome to > >> the century of the fruitbat. > > > > > >> > >> And yes, we have ports written in Rust, why do you ask? > > > > > > pkgbase is the path forward. It is the future. We are better off puttin= g > all our > > horses behind that effort so we can make it the default install in 15.0= . > > > > Once we have that, this whole debate becomes moot, for the most part. > > Userland in rust can compete with userland in C. And with go, python, e= tc > > for whatever does the job the best. If rust is so much better, then > people > > will use it, otherwise they will use the C version. > > How will pkgbase handle the private interface problem? For example, > libifconfig and the /dev/cam/ctl ioctls are both unstable. A port > that uses one of those and is built for FreeBSD 14.0 won't necessarily > work for 14.1. As long as those interfaces' consumers are all within > src there's no problem, but if they move to ports then they'll need to > be rebuilt everytime the libifconfig or kernel port, respectively, > gets rebuilt. > Ah yes. That ABI would have to become stable on stable branches, just like all other ABIs we support. Otherwise, you have to build for all possibilities, which is tricky, or you have to have targeted binaries, which is tedious and error prone, especially for people who are running -stable instead of a release point. Absent a stable ABI, all bets are off. I'm surprised it's not more stable: the rest of CAM is certainly ABI stable across multiple major FreeBSD releases. pkg is close to providing the per-minor-release thing to try to solve the drm-kmod / virtualbox .ko issues. This is one of the features that would need to be fixed, imho, for pkgbase. Though mostly that's because of the port .ko problem. Warner --000000000000b8aed506213b2e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 3, 2024 at 12:18=E2=80=AF= PM Alan Somers <asomers@freebsd.o= rg> wrote:
imp@bsdimp.com> wrote:
>
>
>
> On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp <phk@phk.freebsd.dk>= wrote:
>>
>> As part of the migration, we yank LLVM out of the src.
>
>
>>
>> "pkg upgrade" also upgrade kernel and userland packages = - Welcome to
>> the century of the fruitbat.
>
>
>>
>> And yes, we have ports written in Rust, why do you ask?
>
>
> pkgbase is the path forward. It is the future. We are better off putti= ng all our
> horses behind that effort so we can make it the default install in 15.= 0.
>
> Once we have that, this whole debate becomes moot, for the most part.<= br> > Userland in rust can compete with userland in C. And with go, python, = etc
> for whatever does the job the best. If rust is so much better, then pe= ople
> will use it, otherwise they will use the C version.

How will pkgbase handle the private interface problem?=C2=A0 For example, libifconfig and the /dev/cam/ctl ioctls are both unstable.=C2=A0 A port
that uses one of those and is built for FreeBSD 14.0 won't necessarily<= br> work for 14.1.=C2=A0 As long as those interfaces' consumers are all wit= hin
src there's no problem, but if they move to ports then they'll need= to
be rebuilt everytime the libifconfig or kernel port, respectively,
gets rebuilt.

Ah yes. That ABI would ha= ve to become stable on stable branches,
just like all other ABIs = we support. Otherwise, you have to build for all
possibilities, w= hich is tricky, or you have to have targeted binaries,=C2=A0 which
is tedious and error prone, especially for people who are running -stable=
instead of a release point. Absent a stable ABI, all bets are of= f. I'm surprised
it's not more stable: the rest of CAM is= certainly ABI stable across multiple
major FreeBSD releases.

pkg is close to providing the per-minor-release thing= to try to solve the
drm-kmod / virtualbox .ko issues.
=
This is one of the features that would need to be fixed, imh= o, for pkgbase.
Though mostly that's because of the port .ko = problem.

Warner

--000000000000b8aed506213b2e97-- From nobody Tue Sep 3 19:36:07 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 4Wywps74Wdz52NYX for ; Tue, 03 Sep 2024 19:36:21 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wywps5LNpz4Zvj for ; Tue, 3 Sep 2024 19:36:21 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-70f79f75da6so1454966a34.0 for ; Tue, 03 Sep 2024 12:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725392180; x=1725996980; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=7bx6p5zUL8SQLPPg7DxkI1Rk9qM8yAyVekoQsg5qpFY=; b=FN1tQ9kbZBf/PiCGREqL3G+4VofUrcjnmsf6jnQ1o9oae6Jm1eVEvtGUADJQCVdmZk iWmLQzuV5Q+9yah8j4lwqKdgDCO0mm9jvgbEHrkqlZBUCUu3NiFgnTaI0iQ94v0peSFa pYtwid4cXMRYhAKQibh+tyc5F+mE0q95jDLES/Fg90xo+8t/EWSO6foYwJcAVRPDunwh TY6TgZFcnT7o3ReRPnVgsUIteURMIhIcBCrftKu5qqWbbzD/jdw8JUeRYB2Q6D/7HihN VDRslIO8yRVF4QlNMkf754IeRP+RnhylIpZy6xmaP8nU3vtbiuLOIdo/7nDJlxBy5MvX KbeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725392180; x=1725996980; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7bx6p5zUL8SQLPPg7DxkI1Rk9qM8yAyVekoQsg5qpFY=; b=kPYPaodm+yTzwqfADXdHE9OWNqTLRVXn0dBRZBQYmrCTLHu+flv9oZj6IQ7wyeKPxE TrWSsGR18yDaE86nS9vWQK/kBVpH429516TQpDI2bGoMaN5vNxerDwRh/BBXdx22DyLU o8L81vRPgYEZMEkBsqQDN5Z9gDhtMORUW6TxBkYjElXgVAws1ABPnXl3mPeVJe50Kyfg MvLXbOA682Om+Z2ehnDSF1V4VuOxzbAhBKJZuF6ep+UO8aIgEBXPy350DGAWyIlDrUCh bTBPtzdUxpw1rzuRkjsUn9910VWHI3ORbCBHgjaeTu0R1/t3NEtoV3Iugn1Hq26zfDFW D/5Q== X-Gm-Message-State: AOJu0YzfjieTLbH9jcomum3pxNcprfU+dsGKg4Bcx+qY40o+VdDAHl9X +pgVpwWNJDLnyssibSsfA5wEYJS8cqUTi0QW3H5hPQVpbGnNMpz1 X-Google-Smtp-Source: AGHT+IGczfV59HLHELwZLp8exf+7OmazZfma41h77lmLRTKY6E4twX2x6GL454rp2gz5STVC3y4Tsg== X-Received: by 2002:a05:6830:6e18:b0:708:f1ad:c4bf with SMTP id 46e09a7af769-70f7072d55bmr13972114a34.27.1725392179581; Tue, 03 Sep 2024 12:36:19 -0700 (PDT) Received: from smtpclient.apple (syn-024-097-005-251.biz.spectrum.com. [24.97.5.251]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6c3640804e4sm27694966d6.44.2024.09.03.12.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Sep 2024 12:36:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross 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 (1.0) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 3 Sep 2024 15:36:07 -0400 Message-Id: <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> Cc: freebsd-hackers@freebsd.org In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPhone Mail (21G93) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wywps5LNpz4Zvj > On Sep 3, 2024, at 11:32=E2=80=AFAM, Poul-Henning Kamp wrote: >=20 > =EF=BB=BFWhat is FreeBSD ? > ----------------- >=20 > Forget Rust for the moment, I promise I will come back to it. >=20 > FreeBSD as a project was created almost entirely as protest against > the incompetent "UNIX-industry" as it existed around 1990. >=20 > 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. >=20 > 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. >=20 > ('make world' celebrated 30 years last month! See: 3540f0e14a8) >=20 > The only compiler we had source code for was GCC. We would have > preferred a different license, but we had no choice at the time. >=20 > There were people who, reasonably, thought that X11 was also part > of a "complete UNIX system", but the reality of 1.2MB "3D-printed > save icons" made that a total non-starter, and therefore the ports > collection is FreeBSD's barely younger twin. >=20 > The source tree became our citadel: "FreeBSD is src". If something > was not in src, it was not FreeBSD. >=20 > Buildworld or bust. >=20 > The fight at the gate was fierce at times. >=20 > Delivering a single consistent userland with the kernel has stood > us well for three decades, and we should stick with that. >=20 > But the world has changed, and we all know it, which is why ports, > pkg, freebsd-update and pkgbase exist. >=20 > A FreeBSD system with no installed ports is a rarity today. >=20 > Not even a FreeBSD developers test-machine can avoid git-lite, but > such machines do exist, typically in embedded applications. >=20 > But a FreeBSD system recompiling itself from source is even rarer. >=20 > 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. >=20 > That is objectively absurd. >=20 > The only reason we do that, is because we stil have that outdated > "FreeBSD is src" emotional hangup. >=20 > We need to find a contemporary and useful answer to "What is FreeBSD?" >=20 >=20 > The only answer I can think of > ------------------------------ >=20 > "FreeBSD is ports (some of those ports contain the kernel and userland)" >=20 > As part of the migration, we yank LLVM out of the src. >=20 > 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. >=20 > Our minimal install images will contain: >=20 > The installer > The kernel package(s) > The userland package(s) >=20 > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. >=20 > The "normal install images will also contain: >=20 > The src package(s) > the source code built into kernel and userland packages > The toolchain package(s) > the package used to build the kernel and userland packages > The ports package(s) > the ports tree used to build the toolchain package(s) > All distribution files necessary to build the toolchain package(s) >=20 > (The "toolchain-llvm" (meta-)port may have to be a short-cut, to > not have the llvm port drag in everything and the kitchen-sink, > which would be /precisely/ the same as the llvm which lives in src > today.) >=20 > This distribution format is neither more nor less perfect with > respect to reproducible builds and "Reflections on trusting trust" > than what we have today. >=20 > And yes, we have ports written in Rust, why do you ask? >=20 > Poul-Henning >=20 > PS: I overdosed on release work 25+ years ago, and have not been > paying them much attention since, but if this is what the pkgbase > crew has been pushing for more than a decade, we all owe them an > apology. As a quick note I constantly build freebsd from source. I do it for all of m= y systems for all updates, all patch releases.=20 I may be an outlier here, but my impression from email, forum posts, and red= it threads suggests it is at least somewhat common.=20 There are ways to marry both worlds (like poudriere, which I also use to man= age my empire), but I=E2=80=99d like to not completely discount the usecase;= at the very least the ease of buildworld is important for the releasee engi= neering process itself.=20= From nobody Tue Sep 3 19:50:11 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 4Wyx6s6TgXz52Q6y for ; Tue, 03 Sep 2024 19:50:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wyx6s5Stbz4dYs; Tue, 3 Sep 2024 19:50:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id E92E1892B6; Tue, 03 Sep 2024 19:50:11 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 483JoBuh009465; Tue, 3 Sep 2024 19:50:11 GMT (envelope-from phk) Message-Id: <202409031950.483JoBuh009465@critter.freebsd.dk> To: Alan Somers cc: Warner Losh , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@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: text/plain; charset="us-ascii" Content-ID: <9463.1725393011.1@critter.freebsd.dk> Date: Tue, 03 Sep 2024 19:50:11 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4Wyx6s5Stbz4dYs -------- Alan Somers writes: > For example, libifconfig and the /dev/cam/ctl ioctls are both unstable. > A port that uses one of those and is built for FreeBSD 14.0 won't > necessarily work for 14.1. Isn't that also a problem today ? What difference does it make that src is distributed as a package ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Sep 3 20:13:43 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 4Wyxf83cGlz52S7q for ; Tue, 03 Sep 2024 20:13:52 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4Wyxf81GB7z4k8M for ; Tue, 3 Sep 2024 20:13:52 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 1260 invoked by uid 89); 3 Sep 2024 20:13:45 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 3 Sep 2024 20:13:45 -0000 Message-ID: <062dbaaa-c0cc-49c1-967d-c7f4429f5f76@digitaldaemon.com> Date: Tue, 3 Sep 2024 16:13:43 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: David Cross , Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> Content-Language: en-US From: Jan Knepper In-Reply-To: <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4Wyxf81GB7z4k8M On 9/3/24 15:36, David Cross wrote: > >> On Sep 3, 2024, at 11:32 AM, Poul-Henning Kamp wrote: >> >> What is FreeBSD ? >> ----------------- >> >> Forget Rust for the moment, I promise I will come back to it. >> ... >> ... >> ... >> Poul-Henning >> >> PS: I overdosed on release work 25+ years ago, and have not been >> paying them much attention since, but if this is what the pkgbase >> crew has been pushing for more than a decade, we all owe them an >> apology. > As a quick note I constantly build freebsd from source. I do it for all of my systems for all updates, all patch releases. > > I may be an outlier here, but my impression from email, forum posts, and redit threads suggests it is at least somewhat common. > > There are ways to marry both worlds (like poudriere, which I also use to manage my empire), but I’d like to not completely discount the usecase; at the very least the ease of buildworld is important for the releasee engineering process > itself. Same here. Not as much anymore as I used to, but it is still my preferred way (a build) to install updates. From nobody Tue Sep 3 20:19:02 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 4WyxmM2yjrz52W8N for ; Tue, 03 Sep 2024 20:19:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyxmM0zCXz4mFC for ; Tue, 3 Sep 2024 20:19:15 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4fd05947340so1656859e0c.3 for ; Tue, 03 Sep 2024 13:19:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725394754; x=1725999554; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FHDKvHm5uJY42AgJPaBUeawGdi6TTVT153y7w/FxvrU=; b=JUL8Wg/3eYCOV88+VqJdc3CFnSrzKfIrHGz25ERjiPk6uzZ7bzgw/lNMJna+4Irs6O wWnL6T5XlLkUhJvvPW64/7xWvZ1OociAxHiTU8yNOWcDbPNVp5rDidPe9VJgOMnob/dj gqKYZ6jNlgJOoH7LrSjpC312/XV8hccUKaxJay0zA4V/gcDGLfiWKtwzm7U4rhkAPckF cIvLHIHMoEp5+vLrjHAq71QiaP2J2nRxBjEiGqdY3sVlfw9zl/QlCRrr9tEfx3KfjVfQ SvnPJgPgDr5JVTY44nDD7lZIiWXAur72SO5UDtiCNQsbIEG3jo0zCpztGbMq0dsnsKv9 AqgA== X-Forwarded-Encrypted: i=1; AJvYcCXdfKktj8+BOtdL1WCGNVRQiXrXfArVFsT4nhzWEDcHZO0F5t/BuGtFVMdxPn6pIgbVPXiDmT7zgAlYQ6FBJu8=@freebsd.org X-Gm-Message-State: AOJu0YzXRij9cl+at/hn90iYZuVdpo3I2vvqLMyFrENqZjN60PFKZTCl ZCHSnaKX2fSPly02qKxUko/LSXTCGxOGU3bx+ODUSLDsukTAtJ3Qz2UrSXptlTMQZtos+IwDMh+ LnNw9G7xNXIqKJbC1E++GlKChdy0= X-Google-Smtp-Source: AGHT+IGijPu4JiBA0AFm+kDUO4/xw2VeHoHRrNeyxFTGPHRosyIujd57kitS8kU6xDsfJ/CN6LwqMs5WT5s8AUCTzoU= X-Received: by 2002:a05:6122:29cb:b0:4f5:254e:e111 with SMTP id 71dfb90a1353d-5009b07f31fmr12586350e0c.7.1725394753837; Tue, 03 Sep 2024 13:19:13 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> In-Reply-To: <202409031950.483JoBuh009465@critter.freebsd.dk> From: Alan Somers Date: Tue, 3 Sep 2024 14:19:02 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Poul-Henning Kamp Cc: Warner Losh , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WyxmM0zCXz4mFC On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp wrote: > > -------- > Alan Somers writes: > > > For example, libifconfig and the /dev/cam/ctl ioctls are both unstable. > > A port that uses one of those and is built for FreeBSD 14.0 won't > > necessarily work for 14.1. > > Isn't that also a problem today ? > > What difference does it make that src is distributed as a package ? Not "a package" but "many packages". The pkgbase concept builds a separate package for almost every dir under lib, bin, sbin, usr.bin, and usr.sbin. So the problem will be that libifconfig and its consumers will be distributed separately, whereas they are currently distributed together. -Alan From nobody Tue Sep 3 20:21:32 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 4WyxqF2GDmz52YJC for ; Tue, 03 Sep 2024 20:21:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyxqF0dTqz4p0n for ; Tue, 3 Sep 2024 20:21:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2da4ea973bdso1232079a91.1 for ; Tue, 03 Sep 2024 13:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725394904; x=1725999704; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NTJqJExBWedSLL8MJrzQsx+DPBRpfgC0oJtveTUJT88=; b=QvKF+bv72AVZw9txD1h5HwzTdCKJLpuoHxu/3VN4rXcXWjuHhBA79J9YpmUV1xmucA D3r/a2XYQkEVf8s+Iu/UdbQkyMgeliyXoezphUhDMux0Sc6foS8rHh44GVZWZtgUfBHz 9sGbKrWRIid1EMJRt+tj2f1vVwzZAoIDek/19+cl6eOySKcEBJ4CyoJ9CK2WH4RASNw6 O25a/2spTRYi9v65av2orx3fFBw7/eZ7yJ+um/UHgrIc0G9A5+bqsp7pMmOWm+7Zt/TZ LIADRj2JGo7DZfUDxMIwwSKjuMkyrtBkybXob3hg/sdSf0R6aUvuiERfdCc1RZ+KhFQM fhJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725394904; x=1725999704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NTJqJExBWedSLL8MJrzQsx+DPBRpfgC0oJtveTUJT88=; b=fgfGR1rUS3JXJsan4Wtd9vzTpV4JK03Pfg66W1ukXogosP9xE6CJLPVymgDRqiQtPA LiIqX0rDxA9TG2K3dd/1R1Mkmu5FYu2cWnmjP4Npud/e9EmXCo2wFu6i7A87u6gwY4Ia q9SNzQ+8OytAYdIvjBH1rm4ydQXfeCOg+DdN2VzjTUheAYHhdOg7dVe6+3AShxRz3dnI lfw8Tiv2LSjryXhxEgK2freTt39whsvmehtV/7yeJu6uXvdzEyYIyvdWjaghaJxBc5UA 2Th7KLFqpO8d+t58yd6pV50YiKARkQ3MGkCpIH1FotZ5kqEquK3q6z9SUzvSdgGLXgN5 20sQ== X-Forwarded-Encrypted: i=1; AJvYcCVVgZF1oBz3D/K/fkxyq9UdPq763B6jGjfyE4WYXBpZx6oU6aIvLrmfm6GZCs/NVXV4UAxgrRQSqxCmMclXlkc=@freebsd.org X-Gm-Message-State: AOJu0YynCF6oCF4vleBfyfsq0tyUuoMIwtLrrvhbuprnVSjZmkUjccj2 ldRygxSu+A1WIUN2e0CSoqyexA7vuIeRTigCYIU8cdfubRLkdHJ9HjRgDx5PnhvSYatZN3nJdVm 0//7kE1C1e7wNQ8OoM9MGtZHoym9MvKi6AdcDXGRi7vMTUKMu X-Google-Smtp-Source: AGHT+IHc9JcdcRtqOPJm5pS5URjaXzClW+riOdOl07wOmzUdPMSBUEpltdpHTg6zz5bBXn7UY9JFKA2P2USWA9NSBEk= X-Received: by 2002:a17:90b:198c:b0:2d8:8f16:17a1 with SMTP id 98e67ed59e1d1-2d88f163805mr13376445a91.14.1725394903775; Tue, 03 Sep 2024 13:21:43 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Tue, 3 Sep 2024 14:21:32 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Alan Somers Cc: Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000056585306213cce70" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WyxqF0dTqz4p0n --00000000000056585306213cce70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers wrot= e: > On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp > wrote: > > > > -------- > > Alan Somers writes: > > > > > For example, libifconfig and the /dev/cam/ctl ioctls are both unstabl= e. > > > A port that uses one of those and is built for FreeBSD 14.0 won't > > > necessarily work for 14.1. > > > > Isn't that also a problem today ? > > > > What difference does it make that src is distributed as a package ? > > Not "a package" but "many packages". The pkgbase concept builds a > separate package for almost every dir under lib, bin, sbin, usr.bin, > and usr.sbin. So the problem will be that libifconfig and its > consumers will be distributed separately, whereas they are currently > distributed together. > Won't versions and dependencies solve this? They aren't tied to a kernel version since its a stable ABI. Warnrr > -Alan > --00000000000056585306213cce70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers <<= a href=3D"mailto:asomers@freebsd.org">asomers@freebsd.org> wrote:
On Tue, Sep 3, 2024 at 1:50=E2=80=AFP= M Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> Alan Somers writes:
>
> > For example, libifconfig and the /dev/cam/ctl ioctls are both uns= table.
> > A port that uses one of those and is built for FreeBSD 14.0 won&#= 39;t
> > necessarily work for 14.1.
>
> Isn't that also a problem today ?
>
> What difference does it make that src is distributed as a package ?
Not "a package" but "many packages".=C2=A0 The pkgbase = concept builds a
separate package for almost every dir under lib, bin, sbin, usr.bin,
and usr.sbin.=C2=A0 So the problem will be that libifconfig and its
consumers will be distributed separately, whereas they are currently
distributed together.

Won't versions and dependencies solve this? They a= ren't tied to a kernel version since its a stable ABI.

Warnrr
-Alan
--00000000000056585306213cce70-- From nobody Tue Sep 3 20:40:24 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 4WyyF21xrzz52ZZt for ; Tue, 03 Sep 2024 20:40:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyyF209qxz4rgv for ; Tue, 3 Sep 2024 20:40:38 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-4fd142a798eso1608635e0c.3 for ; Tue, 03 Sep 2024 13:40:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725396037; x=1726000837; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GXaFLVTHHCa9uuT4BemLz+iK/s5przOmcfAzOTk6eIA=; b=uNvcGfPfCKRxZ0jwj5wromJDqAEH6RYipMP6hseM3ZNidu91bLZFh2r4Sp6NntgkKA JRvY7tQwqKt9MzYeAeydt7Z7F6qQAx9kvxjz8DBAiYWhoH/qVeyjrFaNYxZxUzQrLYlh MoUh38OINY4vl7zVEiXLwyQWTs6zim/NtSNMznRHWE0lYrZ43hQxElRMc9K5zhunpozF 6+z3CpwXAvgKeZEPCGvCIz/SFZqrDmXd1Px9n4h1mA015F3E7KrgaiBgferlA656bHXi 8C2LGv6jlcoSVXll22wZ+2WSySULXhScD7ZcUUkt3VOgdXKnSx9DKL0+iLQpbW/CSnBQ mc/A== X-Forwarded-Encrypted: i=1; AJvYcCWuQy8EOq0FtvWRiGbZ5unHMCh9qQPrQQxGPt6UHHVfMzFw7dE9t40qN34YcR0U4NDIWjS6EnyxbkRC+bzZSIs=@freebsd.org X-Gm-Message-State: AOJu0Yz7M0KwlC1DyqiwfNb8e4wK03SBFJoUI9jNBtWxsHO54bpcfC77 l7VwoLGyYD78OX1n8WB27jfmd0RhnKXlFu6fbhevEvXBoVWHq8U/Q7i6jrWYWxn3DklVWDbPAV7 6OlSdxAjzzhBABsAIWN5NF4+A2w0= X-Google-Smtp-Source: AGHT+IHExfJ1l5mF0qLvf3k9waONi+sISTLNd7H71yk4YjNnn8eaEt//x9PTIqkFPxuYPm93D5jwmvCT6mk1utE8cm8= X-Received: by 2002:a05:6122:2010:b0:4ef:5b2c:df41 with SMTP id 71dfb90a1353d-500de23b40amr4042873e0c.9.1725396036920; Tue, 03 Sep 2024 13:40:36 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> In-Reply-To: From: Alan Somers Date: Tue, 3 Sep 2024 14:40:24 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Warner Losh Cc: Poul-Henning Kamp , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WyyF209qxz4rgv On Tue, Sep 3, 2024 at 2:21=E2=80=AFPM Warner Losh wrote: > > > > On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers wr= ote: >> >> On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp wrote: >> > >> > -------- >> > Alan Somers writes: >> > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both unstab= le. >> > > A port that uses one of those and is built for FreeBSD 14.0 won't >> > > necessarily work for 14.1. >> > >> > Isn't that also a problem today ? >> > >> > What difference does it make that src is distributed as a package ? >> >> Not "a package" but "many packages". The pkgbase concept builds a >> separate package for almost every dir under lib, bin, sbin, usr.bin, >> and usr.sbin. So the problem will be that libifconfig and its >> consumers will be distributed separately, whereas they are currently >> distributed together. > > > Won't versions and dependencies solve this? They aren't tied to a kernel = version since its a stable ABI. > > Warnrr >> >> -Alan Aren't you the one who just said that the ABI will need to become stable? Or did you only mean that about the /dev/cam/ctl ioctls? For private libs, the easiest thing would be if pkgbase could put libs and their consumers into the same package. But that might not always be possible. From nobody Tue Sep 3 21:33:27 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 4WyzQ96l2Rz5MT6g for ; Tue, 03 Sep 2024 21:33:37 +0000 (UTC) (envelope-from SRS0=Yejt=QB=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyzQ92XjQz41Bt for ; Tue, 3 Sep 2024 21:33:37 +0000 (UTC) (envelope-from SRS0=Yejt=QB=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 84243D78AC; Tue, 3 Sep 2024 23:33:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1725399209; bh=wMQFWrRMAdzsMcbWI8XS0sfjslY55c2+B/9dBGOmaPA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=pSsKgwNWeeJxhb6E4WGM0iYC+oy/HNdvFcWAPTDkpdzvw4ufsH5jFmDskf8yWp4iH QhDPScnqRtS61r8OKy6OUzv6TKcFeiqDE/rDEUlHQh6VZUS3i68pAnr8kn6o5TbotA Pv/jSdtSdIefR6YqM3MvUdvxkfViVgGlac7x7icg= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 97F49D78DB; Tue, 3 Sep 2024 23:33:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1725399207; bh=wMQFWrRMAdzsMcbWI8XS0sfjslY55c2+B/9dBGOmaPA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=vpm0KJllqmr6tfBAUpRy4H8HdunzSsJVbhFuao0CBk4suUkPt8gQX6tmK1f8IZ0Pv yfnTZC/JBIvutEVm/O0zwpPQggNnRfc1+CJ4WSPniL+I4V1IPyR7YGlU9c4Hl4cJ5R 31s3dUXzwd8S+icIXwIFf8XxYWRXY8UeMVGDANNE= Message-ID: <2915699d-5139-43fd-80af-877c1d290e8d@quip.cz> Date: Tue, 3 Sep 2024 23:33:27 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: David Cross , Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] X-Rspamd-Queue-Id: 4WyzQ92XjQz41Bt On 03/09/2024 21:36, David Cross wrote: [..] >> (The "toolchain-llvm" (meta-)port may have to be a short-cut, to >> not have the llvm port drag in everything and the kitchen-sink, >> which would be /precisely/ the same as the llvm which lives in src >> today.) >> >> This distribution format is neither more nor less perfect with >> respect to reproducible builds and "Reflections on trusting trust" >> than what we have today. >> >> And yes, we have ports written in Rust, why do you ask? >> >> Poul-Henning >> >> PS: I overdosed on release work 25+ years ago, and have not been >> paying them much attention since, but if this is what the pkgbase >> crew has been pushing for more than a decade, we all owe them an >> apology. > > As a quick note I constantly build freebsd from source. I do it for all of my systems for all updates, all patch releases. > > I may be an outlier here, but my impression from email, forum posts, and redit threads suggests it is at least somewhat common. > > There are ways to marry both worlds (like poudriere, which I also use to manage my empire), but I’d like to not completely discount the usecase; at the very least the ease of buildworld is important for the releasee engineering process > itself. We also build every update, or major version upgrade from /usr/src (and then distribute it to target machines by rsync as it is the fastest process for us) But I'm not saying it has to stay that way forever. I agree with what PHK describes. External toolchain or pkg base is a more promising future. Rebuilding LLVM / Rust (you name it) with each update of base or ports is a major pain now. Even if you need to rebuild a small subset of packages from ports you almost always end up rebuilding something that big and slow as LLVM, Rust, Cmake taking hours, but that's a different story. Kind regards Miroslav Lachman From nobody Tue Sep 3 22:13:34 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 4Wz0JP5qVpz5MX4j for ; Tue, 03 Sep 2024 22:13:41 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Wz0JP3WHJz470y for ; Tue, 3 Sep 2024 22:13:41 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 483MDdxe077310; Tue, 3 Sep 2024 23:13:39 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 483MDY1w077309; Tue, 3 Sep 2024 23:13:34 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202409032213.483MDY1w077309@donotpassgo.dyslexicfish.net> Date: Tue, 03 Sep 2024 23:13:34 +0100 Organization: Dyslexic Fish To: phk@phk.freebsd.dk, dcrosstech@gmail.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> In-Reply-To: <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> User-Agent: Heirloom mailx 12.4 7/29/08 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Tue, 03 Sep 2024 23:13:39 +0100 (BST) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] X-Rspamd-Queue-Id: 4Wz0JP3WHJz470y David Cross wrote: > As a quick note I constantly build freebsd from source. I do it for all of my systems for all updates, all patch releases. > > I may be an outlier here, but my impression from email, forum posts, and redit threads suggests it is at least somewhat common. /me too Also, all ports from src rather than pkg. Jamie From nobody Tue Sep 3 22:16:30 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 4Wz0Mv4LbDz5MXVW for ; Tue, 03 Sep 2024 22:16:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz0Mv12Rtz49ks for ; Tue, 3 Sep 2024 22:16:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 483MGV9a083947; Tue, 3 Sep 2024 15:16:37 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1725401797; x=1725402397; r=y; bh=OKr4ILdHY49bazGTLnAQcdkWjOTPfX30eVDPU/dXPVY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=uqNdREyuRnoVx9Mor9XBFQgAESnx5QG2NuveoW9dM2fykCmOo5YqqIIOC8Y4blTKt vkBYtkmg/+tlRIotb84teGTgaGkNfs/5eMJFdUFynPDYWhsMMN001gVDV6E/cUK/Lg ENfun6wg9VOl8SMkXekxeArsuMK+k/CoXg8RXJ9nlxXOgYMcT5473MiB6eOgQuMYIy 6y+YvnwL2k3KvmOWNWmRTPC0/Cd+E2ssYZAh87kO9kvqBX1QAVrALdb1Dl3wqs29bo jsUOCONm6ZJGFiRal1HTUxKZrPbJ9AcScj4E8dEB0GxvVfo//FQGZWZoPnuBk7KiLu 3jzWlY429NcJg== 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 Date: Tue, 03 Sep 2024 15:16:30 -0700 From: Chris To: David Cross Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4Wz0Mv12Rtz49ks On 2024-09-03 12:36, David Cross wrote: >> On Sep 3, 2024, at 11:32 AM, Poul-Henning Kamp wrote: >> >> 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. ... >> >> This distribution format is neither more nor less perfect with >> respect to reproducible builds and "Reflections on trusting trust" >> than what we have today. >> >> And yes, we have ports written in Rust, why do you ask? >> >> Poul-Henning >> >> PS: I overdosed on release work 25+ years ago, and have not been >> paying them much attention since, but if this is what the pkgbase >> crew has been pushing for more than a decade, we all owe them an >> apology. > > As a quick note I constantly build freebsd from source. I do it for all of > my > systems for all updates, all patch releases. > > I may be an outlier here, ... You're definitely not. I build world/kernel for the multitude of servers (and home equipment). For the servers, I only need to do it once (per hardware profile). Where I then simply make images and pour it onto the boot/storage media. In my opinion, the most attractive feature of the BSD's are that there are so darned many options. There is no one-size-fits-all for anything, and the fact that FreeBSD provides so many options to make/install/add/subtract/... provides a near perfect match that tailors to anyone's needs. --Chris From nobody Tue Sep 3 22:31:36 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 4Wz0jG4hjbz5MYfn for ; Tue, 03 Sep 2024 22:31:46 +0000 (UTC) (envelope-from me@levitati.ng) Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz0jG10nlz4Dqq for ; Tue, 3 Sep 2024 22:31:46 +0000 (UTC) (envelope-from me@levitati.ng) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: a=rsa-sha256; b=qtcAJXkMJkZJ/j7TEEj1K1cDP8vPVp9V1XuB/rTm/TdQMzRMSa0OObS+yvk8pFHNlFB0FV2XE48hy/3vvEcrDRtALwSrDKAR+a38VJv05r2ap8qi4FQJQcA9wekG6gzVkp7T/Q0IOqoS2H6tZoZ18uwvT/T7yOMkfULi8ywB9Ltw5OAuF8jTPG+g3/KRD8Wf5tlK2gi2WW6BaE0XB4Hd0d0PkVPDBc0inOB5Z40KK2OlctiR8Gt8KgIzNFGuA3wMMwmKdXPDgdK2GAuq7YfX7lLZZOHuUkJZ5qvKcvCEdlk9AnypnGLOcGZlrFIkRUBrpmHl7kkynro5+inPuAG87g==; s=purelymail1; d=levitati.ng; v=1; bh=LwArNprC3Xf42BO+O0Xktk+iCH7f/J8Mf1/ixAif8i0=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=Kcn/Qg65ExePG4Hpwf8TnyhXcOLIaa1gLmPSrKcuCu0wPCpVRp83AQqD+lnGAeFIypdYl5VweU2qmaKvIrffSuoaLGXme3gg1AbHciobld/EkQ5F1N6olalzBUI1KtVxn7e6eLZY4h/tixcMQ50MgStDN1psPOXEmMBJiJwcX+9v6Pzz7u+eW8oL7g9SssH7w3oynaGNd9Ng5bAGuybEDEXvdq5UkSmBqkrhtG+5CJI7kqfwPc4doiSGJksTL/btdX2KGzfxi8qEPB0Hc7mZhL1G8b0zIbS+2WvFkig/4q+mjZRlu0K/eODsm+P08yli8ZQNXZ5o6bSiGU8X/uzc+A==; s=purelymail1; d=purelymail.com; v=1; bh=LwArNprC3Xf42BO+O0Xktk+iCH7f/J8Mf1/ixAif8i0=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 25799:4744:null:purelymail X-Pm-Original-To: freebsd-hackers@freebsd.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPA id 1394509175; Tue, 03 Sep 2024 22:31:36 +0000 (UTC) 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 Date: Wed, 04 Sep 2024 00:31:36 +0200 From: "Rein Fernhout (Levitating)" 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> User-Agent: Purely Mail via Roundcube/1.6.8 Message-ID: <99fe98c0974bc1778e26097eec3fc244@purelymail.com> X-Sender: me@levitati.ng Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4Wz0jG10nlz4Dqq I actually think Rust could be an opportunity to modernize the FreeBSD src. But if it is decided that no utilities found in FreeBSD will be eligible for a Rust rewrite then I don't see why it should be part of src. I do think Rust is mature enough for adoption into src. These discussions have been riddled with misconceptions about Rust (and its use in the Linux kernel). Each FreeBSD release could just pin a stable release of the Rust toolchain, it is common for Rust projects to have a Minimum Supported Rust Version (MSRV). Also Rust does have an extremely strong ecosystem. It includes gems like the Serde serialization framework and the Clap argument parser. I would personally like to potentially see parts of FreeBSD rewritten in rust. I think it would invite much more contributors in the long term. However I don't see rust rewrites happen anytime soon. And if we only allow new programs in Rust to enter src then I don't think it is worth the burden of supporting a rust toolchain (and its dependencies). On 2024-09-03 17:32, Poul-Henning Kamp wrote: > 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. > > ('make world' celebrated 30 years last month! See: 3540f0e14a8) > > The only compiler we had source code for was GCC. We would have > preferred a different license, but we had no choice at the time. > > There were people who, reasonably, thought that X11 was also part > of a "complete UNIX system", but the reality of 1.2MB "3D-printed > save icons" made that a total non-starter, and therefore the ports > collection is FreeBSD's barely younger twin. > > The source tree became our citadel: "FreeBSD is src". If something > was not in src, it was not FreeBSD. > > Buildworld or bust. > > The fight at the gate was fierce at times. > > Delivering a single consistent userland with the kernel has stood > us well for three decades, and we should stick with that. > > But the world has changed, and we all know it, which is why ports, > pkg, freebsd-update and pkgbase exist. > > A FreeBSD system with no installed ports is a rarity today. > > Not even a FreeBSD developers test-machine can avoid git-lite, but > such machines do exist, typically in embedded applications. > > But a FreeBSD system recompiling itself from source is even rarer. > > 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. > > 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)" > > As part of the migration, we yank LLVM out of the src. > > 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) > > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. > > The "normal install images will also contain: > > The src package(s) > the source code built into kernel and userland packages > The toolchain package(s) > the package used to build the kernel and userland packages > The ports package(s) > the ports tree used to build the toolchain package(s) > All distribution files necessary to build the toolchain package(s) > > (The "toolchain-llvm" (meta-)port may have to be a short-cut, to > not have the llvm port drag in everything and the kitchen-sink, > which would be /precisely/ the same as the llvm which lives in src > today.) > > This distribution format is neither more nor less perfect with > respect to reproducible builds and "Reflections on trusting trust" > than what we have today. > > And yes, we have ports written in Rust, why do you ask? > > Poul-Henning > > PS: I overdosed on release work 25+ years ago, and have not been > paying them much attention since, but if this is what the pkgbase > crew has been pushing for more than a decade, we all owe them an > apology. From nobody Tue Sep 3 22:43:03 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 4Wz0yX60ZPz5MZKb for ; Tue, 03 Sep 2024 22:43:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz0yX4Lk1z4Hfy for ; Tue, 3 Sep 2024 22:43:16 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-846bcf3677dso1212775241.1 for ; Tue, 03 Sep 2024 15:43:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725403395; x=1726008195; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ghku98spQJMnkMckQNVZI9D7dlsA3tR/AyiFs7JtqFE=; b=kBsmokx4hXeT6RfJqlXKnuZZUYtuDrW7qd5AmTjcOHOFHtw3EKX6KceikDZBbAKhCt gUEb8n2wRyJVFcMBKnz3bux0/02jpahqnKSt9hBP+nd/2f61fbU0fco002TciOST4CfA uMiF+1pFP9WXdfOx8jt2nsDOeggcPjSzpEK4TTazurbsVe3RY0cEKutRCqHxBgmGGJSv FNFQxT5bmVGFahY2rUgzHGFNbSEKs/JNPoXH8VmA9EZ2lCV/EmNnqeJ0QZXUvoK2QJu1 sYvWODCyut6BmVKEaN4bhWktR+YdfFr3U1xL9Je9tpD9MC4w3JX19xtm/kLgMQjT60IJ +ZvA== X-Forwarded-Encrypted: i=1; AJvYcCWAeIBh2XiA0J9i5V4ItHAfLeYyiBwLtS6qT6DaZ1IkeRsla1NuHy6UNtI2s8W85AC+AoXAG0DySlIrTmm2OYI=@freebsd.org X-Gm-Message-State: AOJu0YyFJKBkCo6TxLUzF7eUhnk3dWalhVd2B8Pa6zKC5kAg5koYW1AF FeEB+KAuJdUp8zk/5WKMhV/2tVcT95nxwGojoopkvcyqxbt6lp5PjQEsAdIJ851ZKrP/dFUNj3N QPGfS3wQFc2dYantDYP3OCADUHNv0KA== X-Google-Smtp-Source: AGHT+IGIXjiPc1y15WMI36Yl+BwJNJXaL8OQ7lBT0UPY2DLFm+3y4Cp2+AcJeKrU+UnBPffBzQYJXN4WhH6s8qZK8b0= X-Received: by 2002:a05:6122:318a:b0:4f6:a5ed:eb11 with SMTP id 71dfb90a1353d-5009db5acffmr13422382e0c.8.1725403395270; Tue, 03 Sep 2024 15:43:15 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <99fe98c0974bc1778e26097eec3fc244@purelymail.com> In-Reply-To: <99fe98c0974bc1778e26097eec3fc244@purelymail.com> From: Alan Somers Date: Tue, 3 Sep 2024 16:43:03 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: "Rein Fernhout (Levitating)" Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Wz0yX4Lk1z4Hfy On Tue, Sep 3, 2024 at 4:32=E2=80=AFPM Rein Fernhout (Levitating) wrote: > > I actually think Rust could be an opportunity to modernize the FreeBSD > src. > > But if it is decided that no utilities found in FreeBSD will be eligible > for a Rust rewrite then I don't see why it should be part of src. > > I do think Rust is mature enough for adoption into src. These > discussions have been riddled with misconceptions about Rust (and its > use in the Linux kernel). > > Each FreeBSD release could just pin a stable release of the Rust > toolchain, it is common for Rust projects to have a Minimum Supported > Rust Version (MSRV). > Also Rust does have an extremely strong ecosystem. It includes gems like > the Serde serialization framework and the Clap argument parser. > > I would personally like to potentially see parts of FreeBSD rewritten in > rust. > I think it would invite much more contributors in the long term. > However I don't see rust rewrites happen anytime soon. And if we only > allow new programs in Rust to enter src then I don't think it is worth > the burden of supporting a rust toolchain (and its dependencies). +1. We have some utilities of subpar quality that could benefit from a rewrite, even if it must be in C. But it would be easier and less buggy to rewrite them in Rust. As a programmer fluent in both languages, I'm never going to waste my time writing new software (or rewriting old software) in C unless there's a very very good reason. However, the "only new utilities in Rust" limitation isn't completely useless, if it gives us the confidence to allow rewrites later on. -Alan From nobody Tue Sep 3 23:07:53 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 4Wz1WC4wLBz5McqM for ; Tue, 03 Sep 2024 23:08:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz1WC2z7pz4KwH for ; Tue, 3 Sep 2024 23:08:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2d8f06c2459so1553462a91.0 for ; Tue, 03 Sep 2024 16:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725404885; x=1726009685; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i0+u7U41NJSQW0Z6f6IQuS14mLczLvosvwzcU7sp3Es=; b=j2K2SY+UlROhqoaJ2TQCJW0do3FTJoCtDfhsdoPAEWW6bVYToCMiVIuOkisj0fSkoL cFWwVx9E+r1xRoQWU4wgAJETPLgUgaDre7Oc8slqhkyK0Lk0pPJ2+CuSsm5iTPGXQ6vP +TumQ9lXxv53pzzc6DaaFjNRBU/tlw8jEjdTzol5oOf1FliBRa7Vkm5Ym+07mu8JRelj WUGEb8CzVceFdABoeKk06As/1mKtJekv3gYCauw9RsVFvLrhAfQkZwRXBw2VfR+atAtc RxkCacANO9YHTXFyxkBF63KSW1EaCZinPknNsAc12hKLdvO2tEJPzRWPd6b5k4uvIiJB XViw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725404885; x=1726009685; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i0+u7U41NJSQW0Z6f6IQuS14mLczLvosvwzcU7sp3Es=; b=quAt4vaeDlTvQZmf8HRUz3FPy6BBzrnL8kJj73jrvjA/SEOeo+QYWOdBzhhAbzpTGc mRpfZdrfNij32xBohZUnobh88ja0MdQMjkjCHv1ye9CRHeULuG2GvN2U6/nQCkLEEdPk yHA5SPgKtjD4czVlj0e7usEjD0+pw9J8ctSu365gv4wsEpq+qjmMPx9D8sL7hbyd0+aN 6Te7lc2tGT1lHFwCPBZNqRpo82hAcxToVbgvGQQNpgBQ5tlWRJPnQkj/z6tAvrSIKewT Tlg8r7IqjgPNbNUtRMrW8aJU0+l36jCUltbSB8JgijIqgGft86KFaL5nF+8+wotqXLsR jMuQ== X-Forwarded-Encrypted: i=1; AJvYcCXb9A2azwj99LzMW0E+aeZlWg8VRD4gjhFgwKq0WhIcm9w3yqartwA7ivpkyxLdew/ZIdT3Kpnf4wZG0EZ+Dts=@freebsd.org X-Gm-Message-State: AOJu0Yyjd02iYTSuHIKBDIghleKgqf7VdJ6K9iu1ycjiqCDSwsTu1Puo Y8rc3chLrUPE04IEzGBv7FrWGEcW4xotOlILuwm66zjZv+yMuNYUf59Gppgzqo9TplxcVyvk/al fKL75XoWYa2W0ernI/wyTgOlepFBnDToeV5JBjvIs1MRrIwL9 X-Google-Smtp-Source: AGHT+IHi1IgnE22SP+PYp4+qUnM/K8gwZjWQtXq9QwKc3fJnndKz80o+EwTl9Z1++q4axTEPQg1pRbttn/fsIGJLQkM= X-Received: by 2002:a17:90b:2889:b0:2d8:94ae:8ae0 with SMTP id 98e67ed59e1d1-2da5581532fmr5780101a91.0.1725404885477; Tue, 03 Sep 2024 16:08:05 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Tue, 3 Sep 2024 17:07:53 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Alan Somers Cc: Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000004b05c506213f21d1" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wz1WC2z7pz4KwH --0000000000004b05c506213f21d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 2:40=E2=80=AFPM Alan Somers wr= ote: > On Tue, Sep 3, 2024 at 2:21=E2=80=AFPM Warner Losh wrote= : > > > > > > > > On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers = wrote: > >> > >> On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp > wrote: > >> > > >> > -------- > >> > Alan Somers writes: > >> > > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both > unstable. > >> > > A port that uses one of those and is built for FreeBSD 14.0 won't > >> > > necessarily work for 14.1. > >> > > >> > Isn't that also a problem today ? > >> > > >> > What difference does it make that src is distributed as a package ? > >> > >> Not "a package" but "many packages". The pkgbase concept builds a > >> separate package for almost every dir under lib, bin, sbin, usr.bin, > >> and usr.sbin. So the problem will be that libifconfig and its > >> consumers will be distributed separately, whereas they are currently > >> distributed together. > > > > > > Won't versions and dependencies solve this? They aren't tied to a kerne= l > version since its a stable ABI. > > > > Warnrr > >> > >> -Alan > > Aren't you the one who just said that the ABI will need to become > stable? Or did you only mean that about the /dev/cam/ctl ioctls? For > private libs, the easiest thing would be if pkgbase could put libs and > their consumers into the same package. But that might not always be > possible. > Generally, you're supposed to update all the packages in the system, which would keep things from getting cross threaded. However, I had thought that 'pkg upgrade libfoo' would upgrade all things that depended on libfoo. However, it doesn't go 'up' the dependency tree, but just 'down' for things that libfoo depends upon. It's one of the fragile things about pkg today used with ports (though often it's totally fine, since the ABIs are usually stable)... I'm not familiar enough with the ctl ioctl to state definitively... However, it appears, at first blush, to be fairly stable though. Warner --0000000000004b05c506213f21d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 3, 2024 at 2:40=E2=80=AFP= M Alan Somers <= asomers@freebsd.org> wrote:
On Tue, Sep 3, 2024 at 2:21=E2=80=AFPM Warner Losh <<= a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com> w= rote:
>
>
>
> On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers <asomers@freebsd.org> wrote:<= br> >>
>> On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.dk&g= t; wrote:
>> >
>> > --------
>> > Alan Somers writes:
>> >
>> > > For example, libifconfig and the /dev/cam/ctl ioctls are= both unstable.
>> > > A port that uses one of those and is built for FreeBSD 1= 4.0 won't
>> > > necessarily work for 14.1.
>> >
>> > Isn't that also a problem today ?
>> >
>> > What difference does it make that src is distributed as a pac= kage ?
>>
>> Not "a package" but "many packages".=C2=A0 The= pkgbase concept builds a
>> separate package for almost every dir under lib, bin, sbin, usr.bi= n,
>> and usr.sbin.=C2=A0 So the problem will be that libifconfig and it= s
>> consumers will be distributed separately, whereas they are current= ly
>> distributed together.
>
>
> Won't versions and dependencies solve this? They aren't tied t= o a kernel version since its a stable ABI.
>
> Warnrr
>>
>> -Alan

Aren't you the one who just said that the ABI will need to become
stable?=C2=A0 Or did you only mean that about the /dev/cam/ctl ioctls?=C2= =A0 For
private libs, the easiest thing would be if pkgbase could put libs and
their consumers into the same package.=C2=A0 But that might not always be possible.

Generally, you're suppose= d to update all the packages in the system, which would keep
thin= gs from getting cross threaded.

However, I had tho= ught that 'pkg upgrade libfoo' would upgrade all things that depend= ed
on libfoo. However, it doesn't go 'up' the depende= ncy tree, but just 'down' for things that libfoo
depends = upon. It's one of the fragile things about pkg today used with ports (t= hough often
it's totally fine, since the ABIs are usually sta= ble)...

I'm not familiar enough with the ctl i= octl to state definitively... However, it appears, at first blush,
to be fairly stable though.

Warner
--0000000000004b05c506213f21d1-- From nobody Tue Sep 3 23:24:10 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 4Wz1st0sZyz5MdwP for ; Tue, 03 Sep 2024 23:24:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz1ss242gz4Mlj for ; Tue, 3 Sep 2024 23:24:17 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (syn-071-015-252-132.res.spectrum.com [71.15.252.132]) by colo1.denninger.net (Postfix) with ESMTP id 647002110C1 for ; Tue, 03 Sep 2024 19:24:27 -0400 (EDT) Received: from [192.168.10.28] (D18.Denninger.Net [192.168.10.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 3E02C382F4F for ; Tue, 03 Sep 2024 19:24:11 -0400 (EDT) Message-ID: <757f500d-e1bb-4536-ad8a-c2ff45c8baf3@denninger.net> Date: Tue, 3 Sep 2024 19:24:10 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> Content-Language: en-US From: Karl Denninger Autocrypt: addr=karl@denninger.net; keydata= xsFNBF1Rd+gBEACmLAH7SAzdQq57ZN56QQEy0jDFfH5BvGOMZgCaP+Y5lJQ5u9WphCoCALMs Rg0o1Q9DRNWgUmy/cgsxioXAEzZFXXzOHPJhwplVOgfjxnoByD5KQhWG8Owm9QmATdtiZPSV 4UYVNUIbZv7btSnnAXysG2OUHajYS5PVeFQxFbhNFq/SS8VaXr1WEVTFa8NFKp2W3/KY1A+U KKDUlYwnOauK3fnY9chF2IRSoxAbBJFrJ4lPGz04HtzNos4Q9CBfTphKcdFjcPntNS9wrqs3 sm+7hLNTH9B2Kj6aekG5UhD03eyP+gevTgBy51RL6ULzI13Kc4aeyOByuBXrA8D2m2Ee67iy 4+ZSxM9Wn1gQce5624OWzCYIGBH2r75Bshp1KHKu36N2rN//kyKYnwl/z6UZB/S9cMUFKZgL gFx7QxpFX/HvSiBcPfcGS0meModpg6qma7/2jRoQAXacslpiT+uOfRGspNbnglkbw435RzX/ kMUclJQNZBBBUpPiGjVCjeBTiAfN8TyjS+pWzwxNCUZWbYO5xVaS0gbIhgVNoBOGn1rdTsdA PP65SRjaoL5KY6bzkkzrXLB2Djx8/p4vr0qIqxIQWbewJq3xKyKGiqI46ae77BF7k0B++Ndx g9K9UeWKl/iJ0eoI0ftR+xH3aIHTU1Or3j/tj4j8Z0tnVSyt1wARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfwQTAQgAKQUCZj4NhwIbIwUJDK6K2AcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG8twBXrj1l42DQP/A0AGcBuGhHzGh2aFyW94B29 ECEkmkxigmQt++AG9xr3Qv4gC6UtSGzKo50SWAdek5peBRTbeDALa/tQvBsbi2aJgYWxZVOV N2XLe89ZjvJuTZqXaG/iaV50es56/cWBlG7VR+5/ijw3uSWO6gZ+L5bkKnQ/p8OWUP0GbtV1 rmEL4DOf6Sel7vOHGLIOgppMxH3DqAgHINZPhOBn/ySnFYNRUyUzp+DxKweH3/6UT8kLST4z UykLcb6HCXEkPM8ECyXkQacE6AfSsrj+tpDv97ZU9UzfprMGY8MmtpACc2509YhdDgljoaGq dfC2//HDKjEt31apoiKwQ9x2oqDBRtkRJoSuqC+rxRDGYMFdxRUBTEJ/j/P3EJdqCO128Jb+ 2iw+0ERUqMyPJWpRXb+J/zdo4ge5RP39LreyNhblEF3aKIvNMj+KrGwznB0Muny8uP73O/bw w7Nkj6HuXbq9gZ1jV6WqHzP9seadWpxLhcR8UQZqgFbO7Q4Y1Lj7TWt/cEoGXe5TeBGO8/b/ Q0g+LF0+/waARlk9dwVx5vBol4ZJ4gDEwzZD6IqDYB5Knenv/wWAdK7WrzLqP4zBzU5vwpJ+ Aj8i+lkqGcaCdtMdRZpa3qR68eKgutuVCzCt3Ydt2Oeiz/D0ccI++FzJgqfD+r4B1pjWT/V3 SRerR30au23XzsFNBF1Rd+gBEADNVFS8nQ+kpKOpgtP+f3bCVxHAm7eHMbX6oew5yZiQwfD+ 1RWNWLVOMeTt7G2e5HsHpJOUwFUJhbDb0omB0r38xTSVSAig9kmUfb7tTMJG2bG7WfWykBOM WIZ4OhCf+ISv9dUkjNgx4ionWotFxwDiPRwWumVQ7WYZmRZlhDWMiaHgKvBrjJ7Y6GKPRbQc 5/0Qz9xGhXKlFxDQrrSMkyRThIOxXqdfD9z3rEsV3ZwOojzNsnkIImnQMKyIAR0FBQop34G9 wDQi7fxk8wGIfDszwfR4oAdDdPGq4gcAvE7Fd3xKyNpGyjSED5szoaFjldaZSXQIffquSUvy sFCTTLRIso5Dn9uQgi57gIv+5mnyKBfm2Z2P6pEQPSt073TED9rS0+JpniJL7rKRVpO5niqw sQJS6ht+JF88rXro+SiwxD/KeDpTuuJ10+ohLVi1Y+X82X7BIQEhqtFp9FVJSds4o/eNyaHd SoqfoeWMy3EV+rdJ3DneXcPS1BgxO57Rko5Hx3NUSVK83ovFb+Ofes9SLNdqNu3xAUcfpRdS DyxzpVbCq6Y2CIojiaweiYe5BOBhmR9OPGhqP8YD7GukYmQufAVuOrIVyctBlVPHgMBb+UX+ ItYXuX4weSJWLOsmM45xd/EYvBq2DWFpKlyihoktNzTGqxGsNeG7gCOEUTAnUwARAQABwsFl BBgBCAAPBQJmPg2HAhsMBQkMrorYAAoJEG8twBXrj1l4s28P/icoshBPgHA86zWSiBYWtR4M TXbg86Yo5tMm64gO2ipXHlDnS0fQOjkJvfo+1e8soq0Rf4RxvKGEDLF9sxLD3z0ptF4Lj8aN zddLPlWFUZ9iOGbDGZhdvnB6YfCWEOXnkXJHfdheYOd/cni54Y4MT1sPMUiPGDlB4Fpu1voL wMZdGfplQYuV+zYv2ezd6Aoc/YwmhixX3YSjy6vFa+7x8OXrGUK69XaZ649GGHpeZzYuLTPw jAfCjbYBk9a24GtQlO/sk9SHRlxIU1e/AflNMtOMYDwuEDLuPgTLe4pRt4lnSdnQSVsFoYz1 nO7XBtyJdUa2rrhcLfhmSxlbJF/4cmNB4ebyT+5v+9ChpMVqzpKBCjyxPm4s+WVq4aYQ7D24 caCcUknD82iMFDFvbV0dm/xAQKZ3k+L/apMhHtUS23dzhJemxWdeQ6Cs2l0FYoGtrEzfUguR Hj7U3opGU6F4dnH1nQt4CbaXAOXM2Zh4ik+z5xRv9ro7fZUG8KSaz8dHKc2scpnJsqdS5XEk NwcHQUCCwSOEPzbugPJY1vjkjlTGWu6ihN7mjxxfthNPGU21/Vfv0d+mlBNdTkl2YOlQtKci YBqkhRb5Re9KC+6O7dWFf5qPZQiD3iUOxUOWsaQhj/CxO+EYk7kxEJxV4tMZfesE90LgTINX Z7FdWd0DYG+m In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------7kPlG3XboJRWXbAL1O9opkQs" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.79 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[karl]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~] X-Rspamd-Queue-Id: 4Wz1ss242gz4Mlj This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------7kPlG3XboJRWXbAL1O9opkQs Content-Type: multipart/mixed; boundary="------------NQAUL9qKhMaiNxL0TdXfiw9Y"; protected-headers="v1" From: Karl Denninger To: freebsd-hackers@freebsd.org Message-ID: <757f500d-e1bb-4536-ad8a-c2ff45c8baf3@denninger.net> Subject: Re: It's not Rust, it's FreeBSD (and LLVM) References: <202409031532.483FW0If007252@critter.freebsd.dk> <159D15FA-6235-484C-A54A-565E3CDEA690@gmail.com> In-Reply-To: --------------NQAUL9qKhMaiNxL0TdXfiw9Y Content-Type: multipart/alternative; boundary="------------RtfdySRvwTlfMZLZFxvS0e8V" --------------RtfdySRvwTlfMZLZFxvS0e8V Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS8zLzIwMjQgMTg6MTYsIENocmlzIHdyb3RlOg0KPiBPbiAyMDI0LTA5LTAzIDEyOjM2 LCBEYXZpZCBDcm9zcyB3cm90ZToNCj4+PiBPbiBTZXAgMywgMjAyNCwgYXQgMTE6MzLigK9B TSwgUG91bC1IZW5uaW5nIEthbXAgPHBoa0BwaGsuZnJlZWJzZC5kaz4gDQo+Pj4gd3JvdGU6 DQo+Pj4NCj4+PiDvu79XaGF0IGlzIEZyZWVCU0QgPw0KPj4+IC0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4NCj4+PiBGb3JnZXQgUnVzdCBmb3IgdGhlIG1vbWVudCwgSSBwcm9taXNlIEkgd2ls bCBjb21lIGJhY2sgdG8gaXQuDQo+Pj4NCj4+PiBGcmVlQlNEIGFzIGEgcHJvamVjdCB3YXMg Y3JlYXRlZCBhbG1vc3QgZW50aXJlbHkgYXMgcHJvdGVzdCBhZ2FpbnN0DQo+Pj4gdGhlIGlu Y29tcGV0ZW50ICJVTklYLWluZHVzdHJ5IiBhcyBpdCBleGlzdGVkIGFyb3VuZCAxOTkwLg0K PiAuLi4NCj4+Pg0KPj4+IFRoaXMgZGlzdHJpYnV0aW9uIGZvcm1hdCBpcyBuZWl0aGVyIG1v cmUgbm9yIGxlc3MgcGVyZmVjdCB3aXRoDQo+Pj4gcmVzcGVjdCB0byByZXByb2R1Y2libGUg YnVpbGRzIGFuZCAiUmVmbGVjdGlvbnMgb24gdHJ1c3RpbmcgdHJ1c3QiDQo+Pj4gdGhhbiB3 aGF0IHdlIGhhdmUgdG9kYXkuDQo+Pj4NCj4+PiBBbmQgeWVzLCB3ZSBoYXZlIHBvcnRzIHdy aXR0ZW4gaW4gUnVzdCwgd2h5IGRvIHlvdSBhc2s/DQo+Pj4NCj4+PiBQb3VsLUhlbm5pbmcN Cj4+Pg0KPj4+IFBTOiBJIG92ZXJkb3NlZCBvbiByZWxlYXNlIHdvcmsgMjUrIHllYXJzIGFn bywgYW5kIGhhdmUgbm90IGJlZW4NCj4+PiBwYXlpbmcgdGhlbSBtdWNoIGF0dGVudGlvbiBz aW5jZSwgYnV0IGlmIHRoaXMgaXMgd2hhdCB0aGUgcGtnYmFzZQ0KPj4+IGNyZXcgaGFzIGJl ZW4gcHVzaGluZyBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlLCB3ZSBhbGwgb3dlIHRoZW0gYW4N Cj4+PiBhcG9sb2d5Lg0KPj4NCj4+IEFzIGEgcXVpY2sgbm90ZSBJIGNvbnN0YW50bHkgYnVp bGQgZnJlZWJzZCBmcm9tIHNvdXJjZS4gSSBkbyBpdCBmb3IgDQo+PiBhbGwgb2YgbXkNCj4+ IHN5c3RlbXMgZm9yIGFsbCB1cGRhdGVzLCBhbGwgcGF0Y2ggcmVsZWFzZXMuDQo+Pg0KPj4g SSBtYXkgYmUgYW4gb3V0bGllciBoZXJlLCAuLi4NCj4gWW91J3JlIGRlZmluaXRlbHkgbm90 LiBJIGJ1aWxkIHdvcmxkL2tlcm5lbCBmb3IgdGhlIG11bHRpdHVkZSBvZiANCj4gc2VydmVy cyAoYW5kIGhvbWUNCj4gZXF1aXBtZW50KS4gRm9yIHRoZSBzZXJ2ZXJzLCBJIG9ubHkgbmVl ZCB0byBkbyBpdCBvbmNlIChwZXIgaGFyZHdhcmUgDQo+IHByb2ZpbGUpLiBXaGVyZSBJDQo+ IHRoZW4gc2ltcGx5IG1ha2UgaW1hZ2VzIGFuZCBwb3VyIGl0IG9udG8gdGhlIGJvb3Qvc3Rv cmFnZSBtZWRpYS4NCj4NCj4gSW4gbXkgb3BpbmlvbiwgdGhlIG1vc3QgYXR0cmFjdGl2ZSBm ZWF0dXJlIG9mIHRoZSBCU0QncyBhcmUgdGhhdCB0aGVyZSANCj4gYXJlIHNvIGRhcm5lZA0K PiBtYW55IG9wdGlvbnMuIFRoZXJlIGlzIG5vIG9uZS1zaXplLWZpdHMtYWxsIGZvciBhbnl0 aGluZywgYW5kIHRoZSBmYWN0IA0KPiB0aGF0IEZyZWVCU0QNCj4gcHJvdmlkZXMgc28gbWFu eSBvcHRpb25zIHRvIG1ha2UvaW5zdGFsbC9hZGQvc3VidHJhY3QvLi4uIHByb3ZpZGVzIGEg DQo+IG5lYXIgcGVyZmVjdCBtYXRjaA0KPiB0aGF0IHRhaWxvcnMgdG8gYW55b25lJ3MgbmVl ZHMuDQo+DQo+IC0tQ2hyaXMNCj4NCkknbGwgdGhpcmQgdGhhdC4NCg0KL09uZSBvZiB0aGUg cmVhc29ucyBJIHVzZSBGcmVlQlNEIGFsbW9zdC1leGNsdXNpdmVseSwgL2JleW9uZCBteSAN CnBlcnNvbmFsIGZhbWlsaWFyaXR5IChJIHVzZWQgaXQgYXMgdGhlIFVuaXggInBvd2VyIiBp ZiB5b3Ugd2lsbCBiZWhpbmQgDQpteSBJU1AgaW4gdGhlIDE5OTBzKSBpcyB0aGF0IEkgY2Fu IHRhaWxvciBpdCB0aHJvdWdoIHRoZSBzb3VyY2UgYnVpbGQgDQpwcm9jZXNzIHF1aXRlLWVh c2lseSB0byBtdWx0aXBsZSBwdXJwb3Nlcy4NCg0KTXkgcHJpbWFyeSBidWlsZCBhbmQgb3Bl cmF0aW5nIHBsYXRmb3JtIGhlcmUgaXMgL2Fsd2F5cyAvYnVpbHQgYW5kIA0KdXBkYXRlZCBm cm9tIHNvdXJjZSwgYW5kIGhhcyBzZXZlcmFsIHZlcnNpb25zIG9uIGl0IGFzICJ3b3JrdHJl ZXMiIGF0IA0KYW55IGdpdmVuIHBvaW50IGluIHRpbWUuwqAgVGhhdCBpbiB0dXJuIGJ1aWxk cyBib3RoIHJlbGVhc2UgbWVkaWEgL2FuZCANCi9tb3JlLXNwZWNpYWxpemVkICJyZWxlYXNl cyIgdGhhdCBhcmUgbW9yZSAiYXBwbGlhbmNlIiBsaWtlIGZvciBzcGVjaWZpYyANCnB1cnBv c2VzIHdoaWNoIGFyZSB0aGVuIGRlcGxveWVkIHRvIHZhcmlvdXMgcGxhY2VzLsKgIE1vc3Qg b2YgdGhvc2UgYXJlIA0KbmFub2JzZCAob3IgQ3JvY2hldCwgc2FtZSBiYXNpYyBkZWFsKSBi YXNlZCBiZWNhdXNlIHRoZXkgbmVlZCB0byBiZSANCmV4dHJlbWVseSBwb3dlci1mYWlsIHRv bGVyYW50IGFuZCBlZmZlY3RpdmVseSBvcGVyYXRlLCBvdGhlciB0aGFuIHdoZW4gDQpzYXZp bmcgY29uZmlndXJhdGlvbiBjaGFuZ2VzLCB3aXRob3V0IGhhdmluZyB0byBoYXZlIGFuIHIv dyBtb3VudGVkIA0KZmlsZXN5c3RlbSBkdXJpbmcgbm9ybWFsIG9wZXJhdGlvbi7CoCBEdWFs IHBhcnRpdGlvbiBzZXR1cCBhbGxvd3MgZm9yIA0KImxpdmUiIHVwZGF0aW5nOyB1cGRhdGUg dGhlIG5vbi1ydW5uaW5nIG9uZSBhbmQgcmVib290Lg0KDQpJIGFsc28gaGF2ZSBtYWNoaW5l cyBpbi1maWVsZCB0aGF0IGFyZSBiaW5hcnkgdXBkYXRlZCB3aXRoIA0KZnJlZWJzZC11cGRh dGUgLS0gdGhvc2Ugc3lzdGVtcyBhcmUgcXVpdGUgInZhbmlsbGEiIGluIHRlcm1zIG9mIHRo ZWlyIA0KcmVxdWlyZW1lbnRzLsKgIEkgYWxzbyBoYXZlIHN5c3RlbXMgdGhhdCBJIHdhbnQg dG8gYW5kIGRvIHVwZGF0ZSBmcm9tIA0KLVNUQUJMRSB3aGVuIGNvbW1pdHMgY29tZSBpbnRv IHRoZSBjb2RlYmFzZSBidXQgZG9uJ3QgbmVjZXNzYXJpbHkgbWVyaXQgDQphICJyZWxlYXNl LXB4IiBwYXRjaC4NCg0KV2hlbiBsbHZtIGNhbWUgaW50byB0aGUgdG9vb2xjaGFpbiBidWls ZCB0aW1lcyB3ZW50IHZlcnRpY2FsLiANCkZvcnR1bmF0ZWx5IGJ5IHRoZW4gc28gaGFkIHBy b2Nlc3NpbmcgcG93ZXIgYW5kIEkvTyBwZXJmb3JtYW5jZSBmb3IgDQoicmVhc29uYWJsZSIg ZXF1aXBtZW50LCBidXQgcGxlYXNlIGRvIG5vdCBraWQgeW91cnNlbGYgb24gdGhlIGltcGFj dCAtLSANCml0IHdhcyBleHRyZW1lbHkgc2lnbmlmaWNhbnQgaW4gdGhhdCBzZWxmLWhvc3Rl ZCBidWlsZHMgb24gbGVzc2VyIA0KbWFjaGluZXMgYmVjYW1lIGludG9sZXJhYmxlLsKgIFRv ZGF5IEkgY3Jvc3NidWlsZCByYXRoZXIgdGhhbiBuYXRpdmUgaW4gDQpzb21lIGNhc2VzIGJl Y2F1c2UgSSBiYXNpY2FsbHkgL2hhdmUgdG8gL2luIG9yZGVyIHRvIGdldCByZWFzb25hYmxl IA0KYnVpbGQgdGltZXMsIGFuZCBpbmNpZGVudGFsbHkgdGhlcmUncyBhIGhhcmQtdG8tcmVw cm9kdWNlIChhbmQgdGh1cyBmYXIgDQpubyBmaXggYXMgYSByZXN1bHQpIGlzc3VlIEkgaGF2 ZSBvcGVuIGZyb20gaGF2aW5nIHRvIGRvIGl0IHRoYXQgd2F5IA0KcmlnaHQgbm93IGFnYWlu c3Qgc29tZSBBUk0gc3lzdGVtcyANCihodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemls bGEvc2hvd19idWcuY2dpP2lkPTI4MDAzOCkgdGhhdCBzaG93ZWQgDQp1cCB3aXRoIGFuIExM Vk0gZml4IGZvciBhbiBpc3N1ZSB0aGF0IGxvb2tzIGxpa2UgaXQgcmVzdWx0cyBpbiBhbiAN CmFsaWdubWVudCBwcm9ibGVtIHdpdGhpbiBMTFZNIGluIHRoZSB0YXJnZXQgb24gdGhlIGNv ZGUgdGhhdCBnZXRzIGJ1aWx0LCANCmJ1dCBkaXNhcHBlYXJzIGlmIHlvdSB0cnkgdG8gZW5h YmxlIGRlYnVnZ2luZyBzeW1ib2xzLCBhc3NlcnRpb25zIGFuZCANCmV2ZW4gYnVpbGRpbmcg d2l0aCBkZWJ1ZyBmaWxlcyAoYW5kIHRoZW4gcmVtb3ZpbmcgdGhlbSBiZWZvcmUgaW5zdGFs bC4pwqAgDQpPZiBjb3Vyc2Ugd2l0aG91dCBzeW1ib2xzIHRoZSBiYWNrdHJhY2UgaXMgdmVy eSBjbG9zZSB0byB1c2VsZXNzIGluIA0KZmlndXJpbmcgb3V0IGV4YWN0bHkgd2hlcmUgaXRz IHNlZ2ZhdWx0aW5nIGFuZCB3aXRoIHRoZW0gaW5jbHVkZWQgaXQgDQpkb2Vzbid0IGJsb3cg dXAuwqAgV291bGQgdGhpcyBiZSBpbW1lZGlhdGVseSBhYmxlIHRvIGJlIGlzb2xhdGVkIGlu IGEgDQpuYXRpdmUgYnVpbGQgKG9yIGV2ZW4gbm90IGhhcHBlbiBhcyBpdHMgYW4gYXJ0aWZh Y3Qgb2YgDQpjcm9zcy1jb21waWxpbmcpP8KgIEkgZG9uJ3Qga25vdywgYnV0IGF0IDEyIGhv dXJzIGEgY3JhY2sgdG8gdHJ5IG9uIGEgDQpQaTMsIGlmIExMVk0gd2lsbCBldmVuIGJ1aWxk IGF0IGFsbCBvbiB0aGF0IGR1ZSB0byBSQU0gbGltaXRhdGlvbnMsIEknbSANCm5vdCB2ZXJ5 IGluY2xpbmVkIHRvIHRyeSB0byBmaW5kIG91dC7CoCBNeSB3b3JrYXJvdW5kIGZvciB0aGUg cHJlc2VudCBpcyANCnRvIGluY2x1ZGUgdGhlIGRlYnVnIGZpbGVzIC0tIGJ1dCBzdHJpcCB0 aGVtIGZyb20gdGhlIGZpbmlzaGVkIG1lZGlhIC0tIA0Kd2hpY2ggbWFrZXMgdGhlIHByb2Js ZW0gZGlzYXBwZWFyLg0KDQpNYWtpbmcgdGhhdCBzb3J0IG9mIHByb2JsZW0gd29yc2UsIGlu IG15IG9waW5pb24sIGlzIHRvIGJlIGF2b2lkZWQgaWYgDQp0aGUgcHJvamVjdCBjYW4gcmVh c29uYWJseSBkbyBzby4NCg0KLS0gDQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5nZXIu bmV0DQovVGhlIE1hcmtldCBUaWNrZXIvDQovW1MvTUlNRSBlbmNyeXB0ZWQgZW1haWwgcHJl ZmVycmVkXS8NCg== --------------RtfdySRvwTlfMZLZFxvS0e8V Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/3/2024 18:16, Chris wrote:
On 2024-09-03 12:36, David Cross wrote:
On Sep 3, 2024, at 11:32=E2=80=AFAM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

=EF=BB=BFWhat 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.
...

This distribution format is neither more nor less perfect with
respect to reproducible builds and "Reflections on trusting trust"
than what we have today.

And yes, we have ports written in Rust, why do you ask?

Poul-Henning

PS: I overdosed on release work 25+ years ago, and have not been
paying them much attention since, but if this is what the pkgbase
crew has been pushing for more than a decade, we all owe them an
apology.

As a quick note I constantly build freebsd from source. I do it for all of my
systems for all updates, all patch releases.

I may be an outlier here, ...
You're definitely not. I build world/kernel for the multitude of servers (and home
equipment). For the servers, I only need to do it once (per hardware profile). Where I
then simply make images and pour it onto the boot/storage media.

In my opinion, the most attractive feature of the BSD's are that there are so darned
many options. There is no one-size-fits-all for anything, and the fact that FreeBSD
provides so many options to make/install/add/subtract/... provides a near perfect match
that tailors to anyone's needs.

--Chris

I'll third that.

One of the reasons I use FreeBSD almost-exclusively, beyond= my personal familiarity (I used it as the Unix "power" if you will behind my ISP in the 1990s) is that I can tailor it through the source build process quite-easily to multiple purposes.

My primary build and operating platform here is always buil= t and updated from source, and has several versions on it as "worktrees" at any given point in time.=C2=A0 That in turn builds b= oth release media and more-specialized "releases" that are more "appliance" like for specific purposes which are then deployed to various places.=C2=A0 Most of those are nanobsd (or Crochet, same basic deal) based because they need to be extremely power-fail tolerant and effectively operate, other than when saving configuration changes, without having to have an r/w mounted filesystem during normal operation.=C2=A0 Dual partition se= tup allows for "live" updating; update the non-running one and reboot.<= /p>

I also have machines in-field that are binary updated with freebsd-update -- those systems are quite "vanilla" in terms of their requirements.=C2=A0 I also have systems that I want to and do= update from -STABLE when commits come into the codebase but don't necessarily merit a "release-px" patch.

When llvm came into the tooolchain build times went vertical.=C2=A0= Fortunately by then so had processing power and I/O performance for "reasonable" equipment, but please do not kid yourself on the impact -- it was extremely significant in that self-hosted builds on lesser machines became intolerable.=C2=A0 Today I crossbuild rat= her than native in some cases because I basically have to in order to get reasonable build times, and incidentally there's a hard-to-reproduce (and thus far no fix as a result) issue I have open from having to do it that way right now against some ARM systems (https://bugs.freebsd.org/bug= zilla/show_bug.cgi?id=3D280038) that showed up with an LLVM fix for an issue that looks like it results in an alignment problem within LLVM in the target on the code that gets built, but disappears if you try to enable debugging symbols, assertions and even building with debug files (and then removing them before install.)=C2=A0 Of course without symbols the backtrace is very close to useless in figuring out exactly where its segfaulting and with them included it doesn't blow up.=C2=A0 Would this be immediately able to be isolated in a native build (or even not happen as its an artifact of cross-compiling)?=C2=A0 I don't know, but at 12 hours a crack to tr= y on a Pi3, if LLVM will even build at all on that due to RAM limitations, I'm not very inclined to try to find out.=C2=A0 My workaround for the present is to include the debug files -- but strip them from the finished media -- which makes the problem disappear.

Making that sort of problem worse, in my opinion, is to be avoided if the project can reasonably do so.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------RtfdySRvwTlfMZLZFxvS0e8V-- --------------NQAUL9qKhMaiNxL0TdXfiw9Y-- --------------7kPlG3XboJRWXbAL1O9opkQs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEvWWSxnGhSYSUSaCtby3AFeuPWXgFAmbXmpoFAwAAAAAACgkQby3AFeuPWXiw fxAAlEzTP3/ix34jhFtDt+9cU1JG09xFojmgRW8CAEIFg2mfXoanHz78atjiUtKvD9GRqw5WK4OY GXK6ZqKl2moz5Nn/JAJTtVtGda1e82nmoD33pyI3LmLlR5Vj2MP1wU9jksBUrrVWwzo1WcSLTg1s //mz4PgWq9feRd4tT52ihT8YyfPNOqoE6GFYP17wQn1Lhx8aFHgH0gP+Z5+25zc0rYO9TkYZdRX5 9kfu6LSjiQI+xl1Okj8PVsvCPu6pEX83ULmg8lZU8Zvc3Ri61EH2fOPsDBaqrCNSJLq+In7Qsd5m AsrrGT3yCTX+AvVA6Bryx8t6y8hHZTr1HGD0ZewKCxBLCVUPPFi+XRqZB8XutMQb0k2bLWmlVeNH rzDlK0Avq/+v+o5EMWNswjdvroNZQXhkPXqeyTDjLTc4M4tutq7c4WJ03Spnf07MzkKtQwua6cDw jfOhAt8EgfPCPid97kLij1SWE+MlR3y+h9O5IwLEGmMt8NvFkp122QQu0szpj6P0x09jOwugfohw 65wxZgI3mv9h4qSGqXwYofgv/8HrSsvYJ9o4Pd2lfzpNNK4kzZZVlpGx2OkOKRSPZkmZAkk8KwpG 20Pv6Kxebck94qC12h0Zu0LNmLp9Xsyp8V3op8/sscfC+m7gqW4hX4R0hW/Fh3EGrxlutayxSBEW Vs4= =CeW5 -----END PGP SIGNATURE----- --------------7kPlG3XboJRWXbAL1O9opkQs-- From nobody Wed Sep 4 05:49:44 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 4WzBS63BVyz5V9m9 for ; Wed, 04 Sep 2024 05:51:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzBS56ZY2z42Lx; Wed, 4 Sep 2024 05:51:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1725429054; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AF9A1dDtowhIYI2gV5ehasftrIbQCcu+jFRpO57yWPk=; b=EzPj250WpR4QpMWA+oWCbG7+Tuy58XiVF0IMZtoyHaxk0Pqo0UBAD5Kbt70+i0sNrNJop8 cDFB33fRLULvEOhKGO/UWSnDSmzH29KbtcS75q1y47AFOMs9Ir7o7emt6B/fnpejUAQVSa 0n3erGD81NpzExRNdpNHshrH6xTodgo= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 4251bd8d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 4 Sep 2024 05:50:54 +0000 (UTC) Date: Wed, 4 Sep 2024 07:49:44 +0200 From: Emmanuel Vadot To: Alan Somers Cc: Poul-Henning Kamp , Warner Losh , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-Id: <20240904074944.585d0016d115c80b840c15c2@bidouilliste.com> In-Reply-To: References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Queue-Id: 4WzBS56ZY2z42Lx Hi Alan, On Tue, 3 Sep 2024 14:19:02 -0600 Alan Somers wrote: > On Tue, Sep 3, 2024 at 1:50?PM Poul-Henning Kamp wro= te: > > > > -------- > > Alan Somers writes: > > > > > For example, libifconfig and the /dev/cam/ctl ioctls are both unstabl= e. > > > A port that uses one of those and is built for FreeBSD 14.0 won't > > > necessarily work for 14.1. > > > > Isn't that also a problem today ? > > > > What difference does it make that src is distributed as a package ? >=20 > Not "a package" but "many packages". The pkgbase concept builds a > separate package for almost every dir under lib, bin, sbin, usr.bin, > and usr.sbin. Not really true, pkgbase creates a packages for each tools or set of tools (when it make sense). > So the problem will be that libifconfig and its > consumers will be distributed separately, whereas they are currently > distributed together. > -Alan >=20 libifconfig is an internal lib so I'm not sure this is the best example here (and it's internal lib because it's not stable and I don't think that you can use it in a port right now unless the port uses /usr/obj/ from the host or can build the lib from /usr/src, both solution will create problems). But anyway, this isn't a problem to update multiple packages at the same time, yes there will probably be a time during the update where the lib is updated and the binary isn't yet (or the other way around) but that's the same with any ports that depends on a lib present in another ports. Also for sources there is only two packages, FreeBSD-src-sys (for the kernel) and FreeBSD-src (for anything else). I'm not sure that I understand the problem you're trying to describe. Cheers, --=20 Emmanuel Vadot From nobody Wed Sep 4 05:56:09 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 4WzBbH4hm9z5V9hk for ; Wed, 04 Sep 2024 05:57:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzBbH1hNvz43lr; Wed, 4 Sep 2024 05:57:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1725429433; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L7X9HNBzeff2BQVgXUe6iYRTmH0vWSdsUxJimVrqIDw=; b=r28AeMHgVp3pUrjItPdkY5z2b9XEEfXMswHzAuGrWmyH9pSBhDPptE+Xaad8ffvJhZMrY5 1DsqTsDN3cpZwHHL/C7LkmFiPvMWp13kk/76pKoat6OXnyB61Df8p4xxQH39QDXXZmdxgR 443137L8/Oa9L8u7D5lRuYJgwEAUrOc= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e105c83e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 4 Sep 2024 05:57:13 +0000 (UTC) Date: Wed, 4 Sep 2024 07:56:09 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Alan Somers , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-Id: <20240904075609.a07ee81552928a0ecea273cd@bidouilliste.com> In-Reply-To: References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Queue-Id: 4WzBbH1hNvz43lr Hi Warner, On Tue, 3 Sep 2024 17:07:53 -0600 Warner Losh wrote: > On Tue, Sep 3, 2024 at 2:40?PM Alan Somers wrote: >=20 > > On Tue, Sep 3, 2024 at 2:21?PM Warner Losh wrote: > > > > > > > > > > > > On Tue, Sep 3, 2024, 2:19?PM Alan Somers wrote: > > >> > > >> On Tue, Sep 3, 2024 at 1:50?PM Poul-Henning Kamp > > wrote: > > >> > > > >> > -------- > > >> > Alan Somers writes: > > >> > > > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both > > unstable. > > >> > > A port that uses one of those and is built for FreeBSD 14.0 won't > > >> > > necessarily work for 14.1. > > >> > > > >> > Isn't that also a problem today ? > > >> > > > >> > What difference does it make that src is distributed as a package ? > > >> > > >> Not "a package" but "many packages". The pkgbase concept builds a > > >> separate package for almost every dir under lib, bin, sbin, usr.bin, > > >> and usr.sbin. So the problem will be that libifconfig and its > > >> consumers will be distributed separately, whereas they are currently > > >> distributed together. > > > > > > > > > Won't versions and dependencies solve this? They aren't tied to a ker= nel > > version since its a stable ABI. > > > > > > Warnrr > > >> > > >> -Alan > > > > Aren't you the one who just said that the ABI will need to become > > stable? Or did you only mean that about the /dev/cam/ctl ioctls? For > > private libs, the easiest thing would be if pkgbase could put libs and > > their consumers into the same package. But that might not always be > > possible. > > >=20 > Generally, you're supposed to update all the packages in the system, which > would keep > things from getting cross threaded. >=20 > However, I had thought that 'pkg upgrade libfoo' would upgrade all things > that depended > on libfoo. If the lib is properly versioned it will, pkg records any libs that the package depends on in the shlibs_required table and any libs that the package provides in shlibs_provided. So if the package libfoo provides libfoo.so.9 and it's updated to provides libfoo.so.10 any packages that now requires the .10 version will be updated. > However, it doesn't go 'up' the dependency tree, but just 'down' > for things that libfoo > depends upon. It's one of the fragile things about pkg today used with > ports (though often > it's totally fine, since the ABIs are usually stable)... Not sure I follow here. > I'm not familiar enough with the ctl ioctl to state definitively... > However, it appears, at first blush, > to be fairly stable though. >=20 > Warner --=20 Emmanuel Vadot From nobody Wed Sep 4 06:35:23 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 4WzCRR270Sz5VF7K for ; Wed, 04 Sep 2024 06:35:31 +0000 (UTC) (envelope-from lain@fair.moe) Received: from mail.076.ne.jp (mail.076.ne.jp [45.76.218.69]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzCRP0Zz3z4863 for ; Wed, 4 Sep 2024 06:35:28 +0000 (UTC) (envelope-from lain@fair.moe) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=076.ne.jp header.s=dkim header.b=WVko4UBE; dmarc=none; spf=none (mx1.freebsd.org: domain of lain@fair.moe has no SPF policy when checking 45.76.218.69) smtp.mailfrom=lain@fair.moe Received: from mail.076.ne.jp (localhost [127.0.0.1]) by mail.076.ne.jp (Postfix) with ESMTP id 4WzCRJ5FJfzW0mB for ; Wed, 4 Sep 2024 15:35:24 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=076.ne.jp; h= user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:to:from:date; s= dkim; t=1725431724; x=1728023725; bh=yU52crzaX/WvHfpKxOBWpZYzLNL PH+Z712XMErWSPTs=; b=WVko4UBEoPTJ//sKH7OBq2iH46kEixYX4QK80MoQvgK wISnF84k0Lfhcu246+taNqZ+NIS35pM7UZatB+GsKTi8hc2//MSP05P32wf3Lqum b2Z44T9UgDMVE0JzzPV5FXIiqpp8sjESBn9RRgEQCo0ZGBzFlKC+omBN/gEiaUBb ZGiDbFHUCCjza8XBynMmbbGDkA9Nug7lPi34bPJikXlaDq6qm12WAoatGspSeROC wZm7wxjctq5VtebW5C52xFJikUaRAoItyovyAgLj3XfJ+Q/wI7Httduq+9EQ2irB gvQEf0XB5jkZkkG1MzkQu/eADXZ+sGmRR+jCt5Ay0QA== X-Virus-Scanned: Debian amavisd-new at guest.guest Received: from mail.076.ne.jp ([127.0.0.1]) by mail.076.ne.jp (mail.076.ne.jp [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ubCLNBnOtx-a for ; Wed, 4 Sep 2024 15:35:24 +0900 (JST) Received: from mail.fair.moe (124.110.12.171.ap.gmobb-fix.jp [124.110.12.171]) by mail.076.ne.jp (Postfix) with ESMTPSA id 4WzCRH6mJLzW0lR for ; Wed, 4 Sep 2024 15:35:23 +0900 (JST) Date: Wed, 4 Sep 2024 15:35:23 +0900 From: "lain." To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <3wqj34x43r6pyah6fxrzbya7soz3ywe7bdk4poihaeh3hm2d6a@vwk3nh4jxl2r> X-Location: =?utf-8?B?IkVhcnRoL+WcsOeQgyI=?= X-Operating-System: "OpenBSD" References: <202409031131.483BVdax004602@critter.freebsd.dk> <202409031503.aa12667@berenice.pkmab.se> 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="647i2t4rgj6a2gr2" Content-Disposition: inline In-Reply-To: Autocrypt: addr=(null); prefer-encrypt=mutual; keydata= mQGNBGHVL30BDAC2g9WjfETVgMHoWqAQdNDzTFEnuIginZzZdx5CpkBwAeQZexW5Eo/9C1anl4F e0d3KeOFfLMBlaTohsfgvlNyOE8iVyWi5b4Op4cvSfUVm7vQvm+axVVDjXA0o6H4cOWp4etxKfb lD8/kO7WbvMxGeu2IyENoUXZR6/mr1Y6TOWkouTzbWFB1vOxMn68UMouuk4fYf6K3E7KavUMUqu ME3nqFjlKtyQBQmvpe4SnPVnjlOgIHTz9ffGV4l07j3QeCetR2h+CgOFgb1SNLdgxDCuDAdh0iF fGrPQP4jA7BNOcNBdUrkzuNAXDK4H8GB+Z3Pxc2+7jmtPWMPvmpCaZw2jPw2gaey3HPbhxvM1jX gPqLNnr3hKEFGkGPcXwpuxU9saoLOOArLACOkIy9G3GtaU26IJYLCMSi2N8M873oyFOShtcarNY lqetrJ/37tPxdVlOizE0ZB6VD+v6iFpUeHh9aGAiaTIYjM/tfMVUBHjtoQUrJfR8ONxdd1OuHZr e8AEQEAAbQh56We5bGx5byY5piOIDxrYW5heWFtYUAwNzYubmUuanA+iQHOBBMBCAA4AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEXqMTFPwNvHspnw/iU5MGhC0WaM0FAmVQVRoACgkQU5M GhC0WaM0atAv7B/9RsNYsjeCbwDSYqN41A7qipucfxdPpabDeqQgeCYuFPzAaCKl1u+HpF2bb9/ euJlml2pOj4jOKbPr0XyzfDDJEQgHCM7H+mg7CgdpWKeMbOodIgJ4I/rg/a6cVUXZijtrCOXURM eAObcvQRTNTtNqePDgcJ20/3vEB8TPJLbO7Va0YQ0qH9gC36sgmQhksG5UMEpBlStnrY9St+9VX wSB2J3exLt6T2SCCmPM0IG3kAgbtSCzT08MfCHe3s3PL4fqW2SuJeW8p17EzrUFuOhTuQs1oOmJ +2vww4w+1TL5Km45KdxosvzcEzLOh0g+9ml7O2fnVtR3jvSzijFJJCcrn5+Di1EyjrhinEcQQ1+ Oh270wW/NtwWSBQ/peZb2iiuD7Ry/6zgYlLuASCoSXkOZWH76+zRDIEEx4XX3B0bey8qPgyEvXo OFIt9CHCOGwbDVKx0LgXxzYx6JzvJB4xlrQ9zMMmet2GIT6JUIALA25P9jgRep4elNMH9SxiYk0 uQGNBGHVL30BDACdui3F1uwOwgZ8y0zsL2c3Qw6kFVW4sp2ql7w9hz3IbSO7kTrRUqvZ7Wn97AB LRr4piml02S/ljtdlU4P3Hq1hrnRwReG3AWQjJByhZms4VU3QWauUbv/pZti5vuuB7BEmP2txPr npfBBJW5DdPnebc+BecnhsJRE7jegt8XpDWixxyAwmDdmz0hhjL/dYgGzAfx3RD3SZ5c0KhqEHX 5oTOND8/ncInK7hWB1zBq3oaPB2sfzDiUL5eBk+SPvsSoz8rBBsGGnrBX/BIGTIzQ6nB1AIqeze Rcz4R0j/g67/2yz2puwYzr+3QjjfkK4p4ZYuG7nd41CQUWxy3lgUz9kCnxWcR50AHAQhhQGPZKy hicGU1JyJUZMxqyTslSkPa6ziiC2FCOJ77hZV2Ow+4y9usWkTo6Xuce3gfAGV6xgDLarl/P2hN+ DCIV4INlBKj70WaQg2ZlaKatGgVcCrbY5X/PbI9nEFMVOpjo6nXXhf/WI1mRH3lXQJGuiawF8Lm PkAEQEAAYkBtgQYAQgAIAIbDBYhBF6jExT8Dbx7KZ8P4lOTBoQtFmjNBQJlUFUiAAoJEFOTBoQt FmjNfbsL/2jYau5JOYIE0+qjeXe/skuUJ6pRrthXGI/ap7id/XVi7P9IZSDrVEsetNzBvR+9fiu pP1nwAaNS9MaNTb7dwdKutRjrj/X2kFj1HCMJJPJIfmQVdrCaA7AnrBMx4YgA2eAg899LN4v/j5 Y1ljoBxxxJ7OVw30uGCysiMgfQKNFKKRiKMqcfyzF2SImhTO0xBvkjamTmupY0MZdgoK0LDI0bQ dTDOsQJa9D9d25DnH8oCNttapFx9NhVA3+1TG9bJF1JukRyYuHyn7m9GP21hpBjBbvgNtLsZT5a 772XAem0Ro5qLT1BUv+R1B+EtffjKYp8Rhy4VBuSUx3e8ELOdIe+ok1XhrnA5xeMVlPwEADO4jp R09BcYQzA6Fjjo9/yGx1n0TEeYBHfLCggBZlgC66J1XNDIjWc2rNiLUCZh/kZAmlGbG2+3tNFlR DgmMeOKxwPO73VbuJbcMwx7sBNu9TzH2DMVLg8OHzWD6KNg8pYrwVugk1xNjvOroSLqN96uA== User-Agent: NeoMutt/20240201 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.89 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[076.ne.jp:s=dkim]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fair.moe]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.76.192.0/19, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[076.ne.jp:+] X-Rspamd-Queue-Id: 4WzCRP0Zz3z4863 --647i2t4rgj6a2gr2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024=E5=B9=B409=E6=9C=8803=E6=97=A5 07:36, the silly Alan Somers claimed= to have said: I know I reply off Alan, but just to keep it somewhat clean, I'll reply to anyone since my last reply. About C developers being in decline, I actually disagree with that. I have seen younger generations getting interested in C the more they get overwhelmed by the amount of new languages to chose from. And even in the modern languages like Rust or Zig, C still serves as a baseline, so even if those people were to learn any of the modern "low level" languages, they'll learn C eventually anyway. About chosing Rust over C++, C++ might have been a more natural choice =66rom C, but C++ is significantly more bloated and deals with lots of technical debt, which in C is still very minor, despite being older. So even if you rewrite a C program into C++, you'll still be at least doubling the compile times. About DARPA's research, researches in general conducted over the past 130 years or so are mostly just bought and paid for by special interest groups, so not really something you should be taking too seriously, unless it's a large scale randomized control group study, and it's reproducable. I wouldn't doubt that The Rust Foundation put lots of money into DARPA to make them come to the conclusion that we should in fact all rewrite decades upon decades worth of C and C++ code into Rust for no reason. --=20 lain. PGP public key: https://fair.moe/lain.asc --647i2t4rgj6a2gr2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRjt7VGft6AEgroX7Nt5cCzjCJFhwUCZtf/qAAKCRBt5cCzjCJF h9XXAP0RpwX1sA64zzXFsAHS+QxsZJI8eQ+2OavnpYVftozMdAEA8lMjoRu7LSU9 hJTszpKA7g7/mQl+IjcjasCECG1elwA= =2n4k -----END PGP SIGNATURE----- --647i2t4rgj6a2gr2-- From nobody Wed Sep 4 07:43:05 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 4WzDxf3jPdz5VKjJ for ; Wed, 04 Sep 2024 07:43:18 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4WzDxf2vcYz4GvB; Wed, 4 Sep 2024 07:43:18 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725435798; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MHjgehtqaJgQQ/MZK+EFTGeSigYo8MO0kBCpwNKgLWU=; b=Qc6DCleVCq/HKA7YhyhnMzODGpCg4TeY5zgEIosg0bbFWwGUoOzr7OGExhGqaIRHeCn6F1 mB1XOG9eYNS1wZmsuDxLHnQ1zLOMHsCARgjaoK/FHHDYJ44kXuWXEvEiN7klkwoFj3S7B3 +DCi5cCSweqvVFMBoezufdpTtbGQ0thvp9lmgKhJsqUPhQL8Tr3XLBxGXbLGYN243buQXr 7iOUscEWk8F6tmGeUGJRKqNlHtLYZTkOPNh8WYzFzznPjOw95sUMv6ImJKPW0AmcP7D0t0 3oFdi7u5FFCdfSlNK8CV1rbJmK29uiLbE8wO/jCNziso/i74L1eFgt3X9lDttQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725435798; a=rsa-sha256; cv=none; b=Fh7lA2M7M888wF+JlE91XIFFlcvcMkC735iNjELzDRw8yvil29IJ3migTKMr9xndlfT/bb db1fYbsdQ7tcpLtXxHU33Vuew08KxeOZ1gRvUUozNz7Nk4FCV78s0f5q/eWEEXpt7m2twy LflQqEJ/yWcmJKWeOAG1O2G3eqqQ5o/2giSXixKx7pCWk47d6V7AEIkc67svFOZ8tkgQZ2 3IACBUo6lbJ6PBMzrTOLDUxdgV+GOhAg2P7Z1wJ3ZiZBN3vxPSG1/foC71ZJenWFsJsjls yUMqSOpDvrBtV+fBqZaCrP7Er3auJgVOR9wUC4hVBJ6aRv2n5TM5LR2L4mm3Aw== 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=1725435798; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MHjgehtqaJgQQ/MZK+EFTGeSigYo8MO0kBCpwNKgLWU=; b=wEx3z0KB03GKbbqcdUw6IoDXZ21ZcWiQt8t895KQUa3ifMDhi4b8ujFOYdUWVTzxiMcvDx nJnBEEO7YM0fiDfM/vDgyGoWbHWFyMn+Y/mQ9KqC9+8eJoJ+JpsQxeRGDcQUqBppfsGl0f yvt88cIiL1seBX3XCiS/HmHWeCsoqB8fisicvEDyhaLlMQkDAxG5VVMl3uQ93wBi1HOJBu wugwJ05xjSVWKFhpacZWN3ymTY9WR3+cN7lEFmdZKUEPiahF0C9hUNse6zQea+59ZoGeqx 2HKHRIbNhGWSvcg2RolfimoCJIvcnzK3YMy8lYgDLnNZe+lQfs01XKt2zwedQg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzDxf2QGqzFTt; Wed, 4 Sep 2024 07:43:18 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7039F50F6; Wed, 04 Sep 2024 08:43:17 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-BBEBAD78-359E-472A-8202-1182ACB0F90B Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in the base system) Date: Wed, 4 Sep 2024 08:43:05 +0100 Message-Id: <8CAA2984-2168-46ED-8F66-3CE65729D67D@freebsd.org> References: <3wqj34x43r6pyah6fxrzbya7soz3ywe7bdk4poihaeh3hm2d6a@vwk3nh4jxl2r> Cc: freebsd-hackers@freebsd.org In-Reply-To: <3wqj34x43r6pyah6fxrzbya7soz3ywe7bdk4poihaeh3hm2d6a@vwk3nh4jxl2r> To: "lain." X-Mailer: iPad Mail (21G93) --Apple-Mail-BBEBAD78-359E-472A-8202-1182ACB0F90B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4 Sep 2024, at 07:35, lain. wrote: >=20 > About C developers being in decline, I actually disagree with that. > I have seen younger generations getting interested in C the more they > get overwhelmed by the amount of new languages to chose from. This does not reflect my experience in hiring, the data I=E2=80=99ve seen fr= om a major tech company, or the trends in open source contributions. It is far easier to hire C++ developers than C developers. This shift starte= d a bit after C++11 was released and has continued.=20 This trend is reflected in open source. Here is the OpenHub graph: https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontributor= s&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%25= 5B%255D=3D-1&language_name%255B%255D=3D-1&language_name%255B%255D=3D-1&commi= t=3DUpdate This shows the number of open source contributors making contributions in C o= r C++ over the past decade. You=E2=80=99ll see that there are now more than t= hree times as many C++ developers as C contributing to open source projects (= I=E2=80=99m ignoring the last few months where it looks as if C programmers a= ll gave up and went home, I presume there=E2=80=99s an error in the underlyi= ng data). For Rust, the situation is more complicated. Hiring good Rust developers is h= arder than hiring C developers (there are no Rust developers with ten years e= xperience because the language isn=E2=80=99t that old, and even though a lot= of people are learning it, there=E2=80=99s a lot of inertia). This changes a= lot when you look at the open source ecosystem because the fact that Rust i= s new and came from the open-source world skews the people who learn it towa= rds open source and towards wanting to practice the language that they=E2=80= =99ve learned. Here=E2=80=99s the same graph with Rust added: https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontributor= s&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%25= 5B%255D=3Drust&language_name%255B%255D=3D-1&commit=3DUpdate Note that there are still fewer Rust developers than C, but they=E2=80=99re i= ncreasing and they tend to be more enthusiastic contributors. David= --Apple-Mail-BBEBAD78-359E-472A-8202-1182ACB0F90B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 4= Sep 2024, at 07:35, lain. <lain@fair.moe> wrote:

About C developers being in decline, I actually disa= gree with that.
I have seen younger generations getting inte= rested in C the more they
get overwhelmed by the amount of n= ew languages to chose from.

This does not r= eflect my experience in hiring, the data I=E2=80=99ve seen from a major tech= company, or the trends in open source contributions.

It is far easier to hire C++ developers than C developers. This shift sta= rted a bit after C++11 was released and has continued. 

<= /div>
This trend is reflected in open source. Here is the OpenHub graph:=


This sh= ows the number of open source contributors making contributions in C or C++ o= ver the past decade. You=E2=80=99ll see that there are now more than three t= imes as many C++ developers as C contributing to open source projects (I=E2=80= =99m ignoring the last few months where it looks as if C programmers all gav= e up and went home, I presume there=E2=80=99s an error in the underlying dat= a).

For Rust, the situation is more complicated. Hi= ring good Rust developers is harder than hiring C developers (there are no R= ust developers with ten years experience because the language isn=E2=80=99t t= hat old, and even though a lot of people are learning it, there=E2=80=99s a l= ot of inertia). This changes a lot when you look at the open source ecosyste= m because the fact that Rust is new and came from the open-source world skew= s the people who learn it towards open source and towards wanting to practic= e the language that they=E2=80=99ve learned. Here=E2=80=99s the same graph w= ith Rust added:

=

Note that there are still fewer Rust developers than C, b= ut they=E2=80=99re increasing and they tend to be more enthusiastic contribu= tors.

David
= --Apple-Mail-BBEBAD78-359E-472A-8202-1182ACB0F90B-- From nobody Wed Sep 4 07:56:40 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 4WzFF65zNqz5TMbT for ; Wed, 04 Sep 2024 07:56:42 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4WzFF63n6mz4JfR; Wed, 4 Sep 2024 07:56:42 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725436602; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3gf94jYiIjlEhODZRRGHmY3+ei1/re0Fj7Nk1s3WQb8=; b=SRvHSCr0sAPMsZscAFYRnz5BEIoWTK4FEI9l6CAVfcWmtjegMXg3FfTpfJuCxf0me8m/6R f9jjbINEJtyJUVdSRNx/nW+IZ0EBtujdYd654fYTCESmY192q10peLcm3moI+UaPG3/HQk FBCctb90xe6+e9Hzgd4Et9t4pymZk8L/ajI8Qj0vojFh3HGyPPERklf/4YNJImityZRf57 0LyCmUgRVlts4izv3PBHRA4HS7ut3ey6PAMfUeANE7000Opy7LwloJlZRZODUbH7eu4lIV atbRlmlgxkGVqZYhfXAwIMLO+ioPrfXriokTQ8kXHpVcIZtxu0BlM3LGKkAIMw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725436602; a=rsa-sha256; cv=none; b=NhL4F5UzSiLIish6Nsmpbrt8xc5JBTb0srj9FgO0bJysH9hhhltI8Oz/Sk5O7D/ZR5D6o5 wx0lD57O9KWdzV9m/EItCR1xOyBMVrgPfmYIJBUy8fk4VsIkKzo+EB1S20m2nlVHdSdsz0 Jv4p5EoDRQrkolC8QV8nAKkB89gPc3SgOBdWKBNC/Dq833tYWTA7eR+kdi94s/mPOKBwQc q7gfbAUsy6CL2ymrXrTwzvRTaeuUCr2pRmYOeV/iBNprfCSyqo8bWW8ltphBBciOWL523F pwtiTEyFiyziRq4h4b02WOSEeh7IsD+zh17b28kALmC7/wWu5admjG9W6BAQFQ== 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=1725436602; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3gf94jYiIjlEhODZRRGHmY3+ei1/re0Fj7Nk1s3WQb8=; b=JJs2t8ohai0UThz1CiEGRGqMK+p8IYDuxxD2PNd2Xj8XK0u1aFsBYPiUfLCrflyzKIlmNY 3bMoJOMBGzWp7pIf4+MxyylyVJ8BYfED7UmrkiSw216JZ7IX0XQy2MztzrsrxWSbfWvSpv 7DjgfUPHSUlK63fafxpKHbM+bXxNt5dr1d/QLQ6l+r8zKDUy7rEDdvqbEFYITv4bzcqPxf LUaWy/4CrSEB43+l0YCJocuTTJtJcsjkFoykNR9JNlUbmS3DTN73DG8z7NsjBVoyTiM189 HgrhcdaGhpgJuxKkTzw9RBUoPtmD1zMqd0mf4pYAG9XtTZZ6xDgLp5gFmS1LiQ== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzFF62jrrz1RZd; Wed, 4 Sep 2024 07:56:42 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 41E45220D0E; Wed, 4 Sep 2024 09:56:40 +0200 (CEST) Date: Wed, 4 Sep 2024 09:56:40 +0200 From: Baptiste Daroussin To: Alan Somers Cc: Warner Losh , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 03 Sep 14:40, Alan Somers wrote: > On Tue, Sep 3, 2024 at 2:21 PM Warner Losh wrote: > > > > > > > > On Tue, Sep 3, 2024, 2:19 PM Alan Somers wrote: > >> > >> On Tue, Sep 3, 2024 at 1:50 PM Poul-Henning Kamp wrote: > >> > > >> > -------- > >> > Alan Somers writes: > >> > > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both unstable. > >> > > A port that uses one of those and is built for FreeBSD 14.0 won't > >> > > necessarily work for 14.1. > >> > > >> > Isn't that also a problem today ? > >> > > >> > What difference does it make that src is distributed as a package ? > >> > >> Not "a package" but "many packages". The pkgbase concept builds a > >> separate package for almost every dir under lib, bin, sbin, usr.bin, > >> and usr.sbin. So the problem will be that libifconfig and its > >> consumers will be distributed separately, whereas they are currently > >> distributed together. > > > > > > Won't versions and dependencies solve this? They aren't tied to a kernel version since its a stable ABI. > > > > Warnrr > >> > >> -Alan > > Aren't you the one who just said that the ABI will need to become > stable? Or did you only mean that about the /dev/cam/ctl ioctls? For > private libs, the easiest thing would be if pkgbase could put libs and > their consumers into the same package. But that might not always be > possible. > There is 2 things: internal libs and private libs. Internal libs are only static linked and never live anywhere but in the source tree, this means it cannot be used by things built outside of the sourcetree, then there are privatelib, it is perfectly fine for a program built outside of the source tree to be linked to a privatelib as soon as the consumers understands the risks pkg itself is a good example of this as it links to libprivatezstd. Private libs are by designed installed in /usr/lib therefore as soon as we allow pkg at buildtime to lookup for dependency in base (side note: we do not because pkgbase is not officially a thing so nothing is able to declare what base is exposition as things to depend on, but pkg knows how to do it and would work actually better for dependency resolution if we lived in a world where base will be always packaged.) then privatelib dependency perfectly works, there is no need to bundle them into pkg. About the ABI stability, I am claiming since day one of the problem there we should have a list of packages that are tight to minor releases, either marked as such in the ports tree, or extracted out of the ports tree, and we have a dedicated build for those and only for those. this will solve the problem of ABI solition. and pkg supports everything for this to work properly. This means we would have 3 repositories: - https://pkg.freebsd.org/${ABI}/base_release_${VERSION_MINOR}/ - https://pkg.freebsd.org/${ABI}/${VERSION_MINOR}/latest (the packages per release) - https://pkg.freebsd.org/${ABI}/latest We have many actionable options, it just needs someone to actually do one and make it happen. Best regards, Bapt From nobody Wed Sep 4 08:03:13 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 4WzFNk3pJVz5TN8T for ; Wed, 04 Sep 2024 08:03:18 +0000 (UTC) (envelope-from rob@eatenbyagrue.org) Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzFNj5klnz4L2X for ; Wed, 4 Sep 2024 08:03:17 +0000 (UTC) (envelope-from rob@eatenbyagrue.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=despairlabs.com header.s=fm2 header.b=bMPC8U9y; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=VmLXK9LV; dmarc=none; spf=pass (mx1.freebsd.org: domain of rob@eatenbyagrue.org designates 103.168.172.144 as permitted sender) smtp.mailfrom=rob@eatenbyagrue.org Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 3DC0C1380263 for ; Wed, 4 Sep 2024 04:03:17 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Wed, 04 Sep 2024 04:03:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=despairlabs.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1725436997; x=1725523397; bh=v+KT2FR54d D5HP20HaIQyZ7xBu+1FxCb3mvhgPrSJIQ=; b=bMPC8U9ycdAbO5+gkrJmrgjE5u l4KL2TtaQel3pIg7tMXJwGAK7XoVQLcL1tFcjpHHInJRKgV+OTyNcQRVXmebRnJd 5SwC4nU+Rbp/zBGL2SHI9ujmIx3DKPp3vrAmt9EZnR7egjL2Vo3r6DyIdNiv3YIX 5iQslb7czo5PJ5u9Xe3ljANJPeQuio+0sVdzOEn+XGb9/c68oRW20/PuCL3wXya0 iwK04L3J2r0GazUd91QClGqz1fu9xlpHlIGUwVBn6xpBVN7agmzlxTNfObPDgHCP mnOiCFMyiLCkJMNKZjrhvRQ68JkQhjGXCIks2GltOojC1F4hjuPJsoJdNcRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725436997; x=1725523397; bh=v+KT2FR54dD5HP20HaIQyZ7xBu+1 FxCb3mvhgPrSJIQ=; b=VmLXK9LVSaiyqZIiHGrIL6dwTM2gzWq2SrA2e1lobaAW ICNx1GJuQ+Lk8dpYEHG2LhVvAm6o13Vq1ygHIkA/GjOa/Ljtopv/AXPMCRXmcINZ hT+xe1yLujmBlMqOZ6KrNxKTp5PvKzqtnivtXCOPAJScyIxiaRvwPmHG3s+oaj5O W5D32BpZ3e7GqVJ2l3CbGcxMJ4nt/lor6iYu479F4BZzzXKGuWNpZrl7R58RbQvt bRE0aKfkers1GC2+F5v0pIMhiz9/H3b0WnwrKw7bmTAO92yjGaZTFulyfjNa1Z19 QeiEjLxA2QGhGOCZo7fJ65i6MddXtywPrAgHcSv59w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudehiedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvf fukfhfgggtuggjsehttdertddttdejnecuhfhrohhmpeftohgsucfpohhrrhhishcuoehr ohgsnhesuggvshhprghirhhlrggsshdrtghomheqnecuggftrfgrthhtvghrnhephfehud evfeeuudejieegiefggfejvdfhheefheehieeiuedvgfejtdduleffteeunecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosgesvggrthgvnh gshigrghhruhgvrdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhu thdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggsshgurdhorh hg X-ME-Proxy: Feedback-ID: ia7b9477a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 4 Sep 2024 04:03:16 -0400 (EDT) Date: Wed, 4 Sep 2024 18:03:13 +1000 From: Rob Norris To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: References: <202409031131.483BVdax004602@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: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202409031131.483BVdax004602@critter.freebsd.dk> X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[robn@despairlabs.com,rob@eatenbyagrue.org]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.144:from]; R_DKIM_ALLOW(-0.20)[despairlabs.com:s=fm2,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.144:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DMARC_NA(0.00)[despairlabs.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[robn@despairlabs.com,rob@eatenbyagrue.org]; DKIM_TRACE(0.00)[despairlabs.com:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WzFNj5klnz4L2X On 03.09.2024 11:31, Poul-Henning Kamp wrote: > But first and foremost: There has to be a good enough reason. This is a near-enough hook for me to hitch a couple of thoughts on to :) I work on ZFS, primarily on Linux with slowly increasing amounts on FreeBSD too. By a long way, the kind of work that is the slowest and most complicated is around complex locking sequences across multiple threads. In most of these, getting it wrong leads to some kind of data corruption that is usually impossible to track down. The appeal of Rust for me, as for many, is that there are ways to encode those kind of sequencing rules into the type system so that the compiler can tell you where you got it wrong. But, I don't actually want Rust _as such_. I like it a lot, I've written useful programs in Rust over the last decade, and I'd be perfectly happy to use it in kernel and filesystem development if it was available. What I actually want though is high-quality tools to make the kind of problems I need to solve easier for my puny human brain to manage. Rust is an approach to solving some of these kinds of problems. Other approaches exist, have existed, and will exist in the future. This is mostly aimed at the "C is totally fine" crowd. I like C, and I'm pretty good at it, but it absolutely not good enough for many kinds of software. Frankly, I find "just get better at C" to be the most infuratingly facile "argument" against Rust. (And I would _love_ to get better at C. If substantially better C tools are out there (on whatever axis you like to measure that on), then they're either not visible to me, or they're not usable or well-integrated enough to be in my standard kit). There's plenty of plausible reasons not to include Rust in the base system, many of them being discussed on this list, and I'm learning a lot reading along. Just please don't pretend the problems it's trying to solve aren't real. Cheers, Rob. -- Rob Norris | robn.au | robn@despairlabs.com Working on OpenZFS, because there's a lot of data out there and it'd be nice not to lose any of it. From nobody Wed Sep 4 08:05:00 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 4WzFQw247Xz5TNKM for ; Wed, 04 Sep 2024 08:05:12 +0000 (UTC) (envelope-from theraven@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 4WzFQw0Bjfz4LnN; Wed, 4 Sep 2024 08:05:12 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725437112; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wdXfIbTXEJrQRSybKfuq7R+1bpmwdff6B2Y0EqYGbUs=; b=jU3fj6swqlPYGuz3HMZ1fKPEeT3g7Ig+RmCyiMers0qwlrJoiElC/bTsGIwCtCY7FsSBeL 1KcCmpgtA1khsjl+ZEyx1QFbA0V2UD2FRLtiLTCbVOK5vad8ebYy1Avp56/yXq2VJWzZ18 6K1PVK5QJkDiF0Kk9AAy/IBrdkt1tKKR1bzvIlpdmfALx0m9LVTj+5tuaoHstNEKdfywWb nPuWrNdpiaCReNMD9pfFww6VwTEOqN3cRRsHtcXGFFGcUizOv59nmeVGhgmrsE2v28pnru Aa4fRNQMUVHVX2IHaE7z532c/HhnA9KB2M8IYgAp7su8SQkLFAi7/pB97SnVVw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725437112; a=rsa-sha256; cv=none; b=TTKu9f8TxzjMfr0Cq0gSZD7bsFsV/zplFgSo7wkj2u4WjkHag/nQM+S//jJjmR0PDqg7br bbp/KHnMXzyLk0gzkH6O/xWJ3WsLhWjeZf3DUB3coGvdIijdoZn8k9cuF38Oa+LO7xJ0iJ lWWbmZqZaZjNvlEjSExzodfgudKV3qmrETKp3+zrZBUq4NrryIj0vehQTCVavXryLC0B78 7J6bBVNL9Wv0rI0ru5UUHPhMuzmNoUwNYX3UYi1JSoQ4oJNep80jQhCu4KJ+TPsmSTZPYd 4/hEaHANdVYtCFfUkvbNuKtqhyR9ZPOWyYWXoVdiB+a7CTBMumFyR0E8cAXEnA== 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=1725437112; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wdXfIbTXEJrQRSybKfuq7R+1bpmwdff6B2Y0EqYGbUs=; b=CCvlWu0onVVEqq6bxh9JJDGAaxL25Sr6yvGCyWaiJync9cpmgilaLom+UbKNS/s+dUMe36 pPx+Mzosze4YOyvVrYZBk41eu9CnMpuFR21BB4qmcr9Bem92IajoNq1ZlW2mbSjqAqjm7B kc/aY2I+tsTbqMySjxww6WClkONJRx3I5zf3OfPwa23eQ7eLwpb9GO8qQkvJLwGIz2FbY+ lXU0o389gvEGVAi6aGjshkuPWvaphgtkSBo/KtBC3+NfTgTTOwcgYXq08UDScngCmnF4Sx lz+j4g3jAMQ8haDeJj/73ytIfhZNT9c4AMPWoMDhyn9fBbQzz78lYg9Ybjq5jg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzFQv6lStzHS0; Wed, 4 Sep 2024 08:05:11 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 841BB50F7; Wed, 04 Sep 2024 09:05:11 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-1E071F8D-02F9-4215-80E5-9F451BA22255 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in the base system) Date: Wed, 4 Sep 2024 09:05:00 +0100 Message-Id: <9BDCF10F-5422-469D-B052-58A7E2153680@freebsd.org> References: <8CAA2984-2168-46ED-8F66-3CE65729D67D@freebsd.org> Cc: freebsd-hackers@freebsd.org In-Reply-To: <8CAA2984-2168-46ED-8F66-3CE65729D67D@freebsd.org> To: "lain." X-Mailer: iPad Mail (21G93) --Apple-Mail-1E071F8D-02F9-4215-80E5-9F451BA22255 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bah, I failed at copying and pasting the links. Here are the correct links t= o the graphs: C and C++ contributors: https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontributor= s&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%25= 5B%255D=3D-1&commit=3DUpdate And with Rust: https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontributor= s&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%25= 5B%255D=3Drust&language_name%255B%255D=3D-1&commit=3DUpdate David > On 4 Sep 2024, at 08:43, David Chisnall wrote: >=20 > =EF=BB=BF >> On 4 Sep 2024, at 07:35, lain. wrote: >>=20 >> About C developers being in decline, I actually disagree with that. >> I have seen younger generations getting interested in C the more they >> get overwhelmed by the amount of new languages to chose from. >=20 > This does not reflect my experience in hiring, the data I=E2=80=99ve seen f= rom a major tech company, or the trends in open source contributions. >=20 > It is far easier to hire C++ developers than C developers. This shift star= ted a bit after C++11 was released and has continued.=20 >=20 > This trend is reflected in open source. Here is the OpenHub graph: >=20 > https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontribut= ors&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%= 255B%255D=3D-1&language_name%255B%255D=3D-1&language_name%255B%255D=3D-1&com= mit=3DUpdate >=20 > This shows the number of open source contributors making contributions in C= or C++ over the past decade. You=E2=80=99ll see that there are now more tha= n three times as many C++ developers as C contributing to open source projec= ts (I=E2=80=99m ignoring the last few months where it looks as if C programm= ers all gave up and went home, I presume there=E2=80=99s an error in the und= erlying data). >=20 > For Rust, the situation is more complicated. Hiring good Rust developers i= s harder than hiring C developers (there are no Rust developers with ten yea= rs experience because the language isn=E2=80=99t that old, and even though a= lot of people are learning it, there=E2=80=99s a lot of inertia). This chan= ges a lot when you look at the open source ecosystem because the fact that R= ust is new and came from the open-source world skews the people who learn it= towards open source and towards wanting to practice the language that they=E2= =80=99ve learned. Here=E2=80=99s the same graph with Rust added: >=20 > https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontribut= ors&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_name%= 255B%255D=3Drust&language_name%255B%255D=3D-1&commit=3DUpdate >=20 > Note that there are still fewer Rust developers than C, but they=E2=80=99r= e increasing and they tend to be more enthusiastic contributors. >=20 > David --Apple-Mail-1E071F8D-02F9-4215-80E5-9F451BA22255 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Bah= , I failed at copying and pasting the links. Here are the correct links to t= he graphs:

C and C++ contri= butors:



=
And with Rust:


David


On 4 Sep 2024, at 08:43, David Chis= nall <theraven@freebsd.org> wrote:

=EF=BB=BF
On 4 Sep 2024, at 07:35, lain. <lain@fair.moe> wrote:

About C developers being in decline, I actuall= y disagree with that.
I have seen younger generations gettin= g interested in C the more they
get overwhelmed by the amoun= t of new languages to chose from.

This doe= s not reflect my experience in hiring, the data I=E2=80=99ve seen from a maj= or tech company, or the trends in open source contributions.

<= /div>
It is far easier to hire C++ developers than C developers. This sh= ift started a bit after C++11 was released and has continued. 

This trend is reflected in open source. Here is the OpenHub= graph:


T= his shows the number of open source contributors making contributions in C o= r C++ over the past decade. You=E2=80=99ll see that there are now more than t= hree times as many C++ developers as C contributing to open source projects (= I=E2=80=99m ignoring the last few months where it looks as if C programmers a= ll gave up and went home, I presume there=E2=80=99s an error in the underlyi= ng data).

For Rust, the situation is more complicat= ed. Hiring good Rust developers is harder than hiring C developers (there ar= e no Rust developers with ten years experience because the language isn=E2=80= =99t that old, and even though a lot of people are learning it, there=E2=80=99= s a lot of inertia). This changes a lot when you look at the open source eco= system because the fact that Rust is new and came from the open-source world= skews the people who learn it towards open source and towards wanting to pr= actice the language that they=E2=80=99ve learned. Here=E2=80=99s the same gr= aph with Rust added:



<= /html>= --Apple-Mail-1E071F8D-02F9-4215-80E5-9F451BA22255-- From nobody Wed Sep 4 08:46:24 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 4WzGJM4dPNz5TR8P for ; Wed, 04 Sep 2024 08:44:35 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic313-22.consmr.mail.ir2.yahoo.com (sonic313-22.consmr.mail.ir2.yahoo.com [77.238.179.189]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzGJM0295z4T9b for ; Wed, 4 Sep 2024 08:44:34 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725439472; bh=GB0FIgdk6CCAM1EST2rSnNuSY9X83dt6ig1xFIQqXhI=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject:Reply-To; b=ftrMy+bTTnkax4JBghthM/uo4QMRjqCXxCtE6SbabepmwII6oBLDO5kzcP6Sv/6XD3q9LVMvW9aEkNR/iQu8Va+Tm0irM3rmAAh0Mc5Eov8A3y+MVdNj4PH1Hi1uOQmXsiXonR1V4el/DxM7cpEfAP5E4XwtWAFpi0hSj49S0H3T6HPHGA5DExQsh6tzegXwtWTUFPYXhAUSUMeZh45STPATOrb3PiiS5d5cvogOF9CIDFtLrx4fgtl+9SID3cGKownmqSbXlep5Svul/n1C3yKVSBJ50Hfe6r1D+fdbafRdhTZxsuwv3Hgp0bVPnDo3lrjmxrpgItNv+/5hN3wihw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725439472; bh=ZQgZEenaJFx6CXmwbbfpoJKB6Uh5S5cGirxtele2OIa=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YeKXd9jpvM2FvNgCbo6wmug1j1l3vXkp59Tb42WFSOBh3Q95LlxlOmPjo5qjAtP9viEv9gXJLlFJxS4i1IZikT7Kr+lp1VryosGSs2eKYwDLcR/vunC/kunU0/Z+CChB3wGWGCSHpEMldmY1rotru3KI6cJO0vm92M15aQSj7oatiIk3j//2IVr9Qn2DKi970ukyA601f+MBB53ht2fQgfhZK0w2nApRr4TJOfRpB9c8E7uR513zDsAx7tfnFRD9wCWxtBzrTjKFCk4A0rwE4Aei6yhuJURyHhl+2YEpFqyYeJAmp4HjoNjMbZRT9Mw5EHIFYBJldWVfE7lgxwwz7w== X-YMail-OSG: GU5e4kEVM1lL6s9kBqADIS2MAI0fVYjz7BWcOhJjehaTT0pY_.t2lXwYGeNYkoC 9uW9EiZaod6yz5rJHu8Wh06kg4jKzB.xveP6c9yFX2zvrr0cxG.b8PH1YNIx19lC_oUsV5sv.hAG EW3F.7qWikRNFy6sS4CimSRHG_8tkfmBZ0lHg_WBPl6eEblg9WxdiWCF0oy_nVXs96zJpXeHu0sB xLFJc8KbFYCCgGfusjY_hr6GD0Mrjk9G0ryWj6wrBbpqj_qHLSNmCfwS1TfjetGJGG90gsRaT1rV rOKrFg4W.BLeANv0nFSk.W1xYoLIcKIGZowBij33c2IuXzAyI12Q5u1ThnjMGhmX3HnWkn4g2slz AgNQGxJMEm4T318.nSkeggewAbuv6YnPhJCDHMnP_45HFl8mej9fT96SxY.hnT1MyiSkaLXwG1CZ QAjGh34Qlt6watG6rlJmZOKjLF0Bw1vADSvC8YpTzmcKLVuBn65FbAY11yPVcri1NrMNHjyACsxs CFYnOgQFySDVh4F26ylksgEO5Y5phZwX0gF3jVTK8aH1u3HEHU48oR9RVaAs3fANwksSwEHL0No0 7qFJhDCmNqI73P729FMkXy4UUnx5wcz8U0Dkzy7B7ZeYmNUVhbBLDA.uS5r9HsrfweCvUyINqGpf biBlOnqg1P36PjADAl1xrdvLZ8aD7.MYPgNJwQnglQsHXO2513mDkcmJtHFM9gxP8MI_PD2LUr4D JeitSDFCJhHTP_pB3PUmz6zVHx.AgjbeTsPnvIsV3utz5yExI8avzg9oo77mon63Mtm8CYKe81KC eH3GFL2.7lfWSN.r2iMxoBO9ZJn_Thw_ZyNrUWHZxDvrBGKI2fCuRAGBByPUXu8ODW956FmAQdjL eRSrK03TnDKivnaK9095qvnsYwddbWNsqRXITvZnm7DgLnnKdH2hTU3vn3zM4XTL8VtkEUsNxRVO .fi2TlFYU.PzM0kNStHSp80qa8BZXsnifVu50FwR42z7ct.zoBZ35pqqHULu7j5wV9SIDNn77X5Q oWK5AqEjEvH4vKwQYb.Qt9_Kdldg.E0EBpwaPxzdbfMFvK7i1uLdaxGYbTbb.KAqkwoL7J3RUNjd Fmtwh4E7GsfAYcMdF3Gobm.tpF4R_PhJJhZfnlFMGIw4hlihe46JKNOaGzVZab1hkeCqLnddtLJW YUNJXKcuFfO33KxsGIdqTB3RdYuS4wL6Ow.nYbqbbm6gyPHnAvjZKKwtsm9I9QcY1HwL7ReEV1aS MskSIUz_PFZcGSAFcfVv2uEmh8z1fk7sqgtKWhhK1J_yynNHZ6ZVPgD454xrmY3WFJUiUu5vGKky hFqDAFL3EhNJuQdJANJe_49j6pE9keMIT5RLbKBYRB6h5f0g1WyqDzOyTKggD5GZrca1ztmj1w3u kQqpZmYr3aU4SZZYNm.ofaI.e5VqzR02prIwzXgyKF44G4tLS49_4n9oCGEJE5FRGF4bC5igkdXL 38l7OWSwTynMkbYIJh6vx2ld4G5f7OPSo2.uu8zpfHhPRREtx1qRmQKQ5wJEq5s.K9AVV0DuTRhH R3BufHWineuvNrQKkKRtLHg006ETNcLW1Uv1GfSkHS.wDgCqRaiccQnXmnYYea_sAasQ5qGfYGOA 2MJdC3pDdVrIisEhMcuJPKigwGyy3GTrIXcd9jU3spxVNo_UVwe60vUUu90fjn45xg5u7R24khts ah1f9C4Wiw2rLA4.92N9tUxn70ydGSj1.r9DfN..e0JzLjrCu_uAWijJev_G554H0V9eWItQUG17 LFzStm25gN6bfbXCu59zVUfaWcgyez0kSFKuNdR8EClPHk4u3Yy9.xzO5CGNaowHBkxtu0mwPc04 VsICYEG6RA4DmuWBcyhogwQLodEl89ArWiHzIT.FdL5rLYIwP.sHAf52y0ljNSHBsshcFPwXXCgo gR0OyNb7QZfuIHmXa3NcP_gRIefRnjQdqzqrmM2FqM.BoWui.9OMvC6nW6DCSRhBNRfU_ixJvaxs q1qDA3y9V9FVDpAs.Akeel9HzWE4VlHvOjP59cfxbFdJ3qLa7mTbxNcAE4UPm4K2OSt9dXWzMKhD GIX0P0TLBfcAsRJrQCDWwgWyPsWhMUKjK.x.uNxjBUVs0OZDCQnlFD8Wh29K5oQzZVkAWGd6.5Q. 5TYZp73qauOmd.HKf1eCN4rxCH4a9IVpMpgzb1BHav8hdOemHVX.RCpOtAgCBBkY71nuUaxL76LE MasoXibUrVB08.ECW6VpaKJc3 X-Sonic-MF: X-Sonic-ID: 212b81de-9da6-4915-a3f0-7b55643438a2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Wed, 4 Sep 2024 08:44:32 +0000 Received: by hermes--production-ir2-6664f499fc-sk6p8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID da7724715183e7b2144ff3128af2c1c5; Wed, 04 Sep 2024 08:44:31 +0000 (UTC) Date: Wed, 4 Sep 2024 11:46:24 +0300 From: Anthony Pankov Message-ID: <7533543.20240904114624@yahoo.com> To: "Poul-Henning Kamp" , 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> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Queue-Id: 4WzGJM0295z4T9b Hello, Few days ago I builded FreeBSD system with WITHOUT_TOOLCHAIN="yes" for use in VM. Then I have a sly idea to use it for poudriere-jail: let integrate llvm18 package to 'installed' dir and we'll have job done. I have no luck. I somehow put llvm18 into 'installed' dir (dir that ws DESTDIR for installworld) via 'pkg' -r but "poudriere bulk" failed to find a compiler. I stuck with googling 'use llvm from ports as default compiler'. This is what about using external toolchain nowtime. After 15+ years of using FreeBSD I came to the viewpoint that 'FreeBSD is src' in a mean that 'src' is a self-sufficent and is able per se to generate ad hoc operating systems. As for 'self-sufficent' I suggest to test any decision with thought experiment: Someone get FreeBSD and build the system (world/kernel). Then he install builded system on servers. After 5 years he return and want to apply a patch and rebuild system. Would he be successful? In case of ports I definetly answer: "No". Ports system told me to set ALLOW_UNSUPPORTED, then ALLOW_INSECURE, then it failed because certificates of sites changed and it didn't know fresh root CAs. May be I just call for little more care for those who prefer long-lived systems. Sorry for interfering in the conversation. Tuesday, September 3, 2024, 6:32:00 PM, you wrote: > 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. > ('make world' celebrated 30 years last month! See: 3540f0e14a8) > The only compiler we had source code for was GCC. We would have > preferred a different license, but we had no choice at the time. > There were people who, reasonably, thought that X11 was also part > of a "complete UNIX system", but the reality of 1.2MB "3D-printed > save icons" made that a total non-starter, and therefore the ports > collection is FreeBSD's barely younger twin. > The source tree became our citadel: "FreeBSD is src". If something > was not in src, it was not FreeBSD. > Buildworld or bust. > The fight at the gate was fierce at times. > Delivering a single consistent userland with the kernel has stood > us well for three decades, and we should stick with that. > But the world has changed, and we all know it, which is why ports, > pkg, freebsd-update and pkgbase exist. > A FreeBSD system with no installed ports is a rarity today. > Not even a FreeBSD developers test-machine can avoid git-lite, but > such machines do exist, typically in embedded applications. > But a FreeBSD system recompiling itself from source is even rarer. > 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. > 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)" > As part of the migration, we yank LLVM out of the src. > 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) > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. > The "normal install images will also contain: > The src package(s) > the source code built into kernel and userland packages > The toolchain package(s) > the package used to build the kernel and userland packages > The ports package(s) > the ports tree used to build the toolchain package(s) > All distribution files necessary to build the toolchain package(s) > (The "toolchain-llvm" (meta-)port may have to be a short-cut, to > not have the llvm port drag in everything and the kitchen-sink, > which would be /precisely/ the same as the llvm which lives in src > today.) > This distribution format is neither more nor less perfect with > respect to reproducible builds and "Reflections on trusting trust" > than what we have today. > And yes, we have ports written in Rust, why do you ask? > Poul-Henning > PS: I overdosed on release work 25+ years ago, and have not been > paying them much attention since, but if this is what the pkgbase > crew has been pushing for more than a decade, we all owe them an > apology. -- Best regards, Anthony Pankov From nobody Wed Sep 4 08:55:52 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 4WzGYh517Gz5TSGl for ; Wed, 04 Sep 2024 08:56:08 +0000 (UTC) (envelope-from lain@fair.moe) Received: from mail.076.ne.jp (mail.076.ne.jp [45.76.218.69]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzGYg2l6vz4cWd for ; Wed, 4 Sep 2024 08:56:07 +0000 (UTC) (envelope-from lain@fair.moe) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=076.ne.jp header.s=dkim header.b=jm1HFuEC; dmarc=none; spf=none (mx1.freebsd.org: domain of lain@fair.moe has no SPF policy when checking 45.76.218.69) smtp.mailfrom=lain@fair.moe Received: from mail.076.ne.jp (localhost [127.0.0.1]) by mail.076.ne.jp (Postfix) with ESMTP id 4WzGYW0qXdzW0mB for ; Wed, 4 Sep 2024 17:55:59 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=076.ne.jp; h= user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:to:from:date; s= dkim; t=1725440158; x=1728032159; bh=HI3QAgRpXuJ3i5s/z9ZScsIrHqN RmlIA+eSvl5vyP+o=; b=jm1HFuECH9g5sJwohIfQ8/ZfD8EJFi7CBNBAXfN2uSJ +4y5iU3U7skXEn9siGXs77IhiYkByU9nCQ2HCpCZEbIkRyMg9LOSK1BLKU/ZDgOp oCD2mD8QyU6U0eqU7p6tK0jukH5hU/ymMSEsgZG0QV0gUdUbj0pu4SqA3iP/2gx+ TFtUB0Ax0wGpUTyyQmkRjZqX0eYBD0c2je1AvBQrANnK7zDsPPjyDzKfXMf5lnyJ 6J+9WxWekYhVjTU5DOMXlynFFJOLpTXhUalZHxunn5BMHWPWKVEDkHIlyOLgOy0o wiu7rtFvl1X0r/awXy2jT6619oaKqJyg5MXPpsz4+Cg== X-Virus-Scanned: Debian amavisd-new at guest.guest Received: from mail.076.ne.jp ([127.0.0.1]) by mail.076.ne.jp (mail.076.ne.jp [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wL4a5GbeSufW for ; Wed, 4 Sep 2024 17:55:58 +0900 (JST) Received: from mail.fair.moe (unknown [133.106.37.36]) by mail.076.ne.jp (Postfix) with ESMTPSA id 4WzGYP62LCzW0lR for ; Wed, 4 Sep 2024 17:55:53 +0900 (JST) Date: Wed, 4 Sep 2024 17:55:52 +0900 From: "lain." To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: X-Location: =?utf-8?B?IkVhcnRoL+WcsOeQgyI=?= X-Operating-System: "OpenBSD" References: <3wqj34x43r6pyah6fxrzbya7soz3ywe7bdk4poihaeh3hm2d6a@vwk3nh4jxl2r> <8CAA2984-2168-46ED-8F66-3CE65729D67D@freebsd.org> 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kgtpmmdnfkuvdnbq" Content-Disposition: inline In-Reply-To: <8CAA2984-2168-46ED-8F66-3CE65729D67D@freebsd.org> Autocrypt: addr=(null); prefer-encrypt=mutual; keydata= mQGNBGHVL30BDAC2g9WjfETVgMHoWqAQdNDzTFEnuIginZzZdx5CpkBwAeQZexW5Eo/9C1anl4F e0d3KeOFfLMBlaTohsfgvlNyOE8iVyWi5b4Op4cvSfUVm7vQvm+axVVDjXA0o6H4cOWp4etxKfb lD8/kO7WbvMxGeu2IyENoUXZR6/mr1Y6TOWkouTzbWFB1vOxMn68UMouuk4fYf6K3E7KavUMUqu ME3nqFjlKtyQBQmvpe4SnPVnjlOgIHTz9ffGV4l07j3QeCetR2h+CgOFgb1SNLdgxDCuDAdh0iF fGrPQP4jA7BNOcNBdUrkzuNAXDK4H8GB+Z3Pxc2+7jmtPWMPvmpCaZw2jPw2gaey3HPbhxvM1jX gPqLNnr3hKEFGkGPcXwpuxU9saoLOOArLACOkIy9G3GtaU26IJYLCMSi2N8M873oyFOShtcarNY lqetrJ/37tPxdVlOizE0ZB6VD+v6iFpUeHh9aGAiaTIYjM/tfMVUBHjtoQUrJfR8ONxdd1OuHZr e8AEQEAAbQh56We5bGx5byY5piOIDxrYW5heWFtYUAwNzYubmUuanA+iQHOBBMBCAA4AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEXqMTFPwNvHspnw/iU5MGhC0WaM0FAmVQVRoACgkQU5M GhC0WaM0atAv7B/9RsNYsjeCbwDSYqN41A7qipucfxdPpabDeqQgeCYuFPzAaCKl1u+HpF2bb9/ euJlml2pOj4jOKbPr0XyzfDDJEQgHCM7H+mg7CgdpWKeMbOodIgJ4I/rg/a6cVUXZijtrCOXURM eAObcvQRTNTtNqePDgcJ20/3vEB8TPJLbO7Va0YQ0qH9gC36sgmQhksG5UMEpBlStnrY9St+9VX wSB2J3exLt6T2SCCmPM0IG3kAgbtSCzT08MfCHe3s3PL4fqW2SuJeW8p17EzrUFuOhTuQs1oOmJ +2vww4w+1TL5Km45KdxosvzcEzLOh0g+9ml7O2fnVtR3jvSzijFJJCcrn5+Di1EyjrhinEcQQ1+ Oh270wW/NtwWSBQ/peZb2iiuD7Ry/6zgYlLuASCoSXkOZWH76+zRDIEEx4XX3B0bey8qPgyEvXo OFIt9CHCOGwbDVKx0LgXxzYx6JzvJB4xlrQ9zMMmet2GIT6JUIALA25P9jgRep4elNMH9SxiYk0 uQGNBGHVL30BDACdui3F1uwOwgZ8y0zsL2c3Qw6kFVW4sp2ql7w9hz3IbSO7kTrRUqvZ7Wn97AB LRr4piml02S/ljtdlU4P3Hq1hrnRwReG3AWQjJByhZms4VU3QWauUbv/pZti5vuuB7BEmP2txPr npfBBJW5DdPnebc+BecnhsJRE7jegt8XpDWixxyAwmDdmz0hhjL/dYgGzAfx3RD3SZ5c0KhqEHX 5oTOND8/ncInK7hWB1zBq3oaPB2sfzDiUL5eBk+SPvsSoz8rBBsGGnrBX/BIGTIzQ6nB1AIqeze Rcz4R0j/g67/2yz2puwYzr+3QjjfkK4p4ZYuG7nd41CQUWxy3lgUz9kCnxWcR50AHAQhhQGPZKy hicGU1JyJUZMxqyTslSkPa6ziiC2FCOJ77hZV2Ow+4y9usWkTo6Xuce3gfAGV6xgDLarl/P2hN+ DCIV4INlBKj70WaQg2ZlaKatGgVcCrbY5X/PbI9nEFMVOpjo6nXXhf/WI1mRH3lXQJGuiawF8Lm PkAEQEAAYkBtgQYAQgAIAIbDBYhBF6jExT8Dbx7KZ8P4lOTBoQtFmjNBQJlUFUiAAoJEFOTBoQt FmjNfbsL/2jYau5JOYIE0+qjeXe/skuUJ6pRrthXGI/ap7id/XVi7P9IZSDrVEsetNzBvR+9fiu pP1nwAaNS9MaNTb7dwdKutRjrj/X2kFj1HCMJJPJIfmQVdrCaA7AnrBMx4YgA2eAg899LN4v/j5 Y1ljoBxxxJ7OVw30uGCysiMgfQKNFKKRiKMqcfyzF2SImhTO0xBvkjamTmupY0MZdgoK0LDI0bQ dTDOsQJa9D9d25DnH8oCNttapFx9NhVA3+1TG9bJF1JukRyYuHyn7m9GP21hpBjBbvgNtLsZT5a 772XAem0Ro5qLT1BUv+R1B+EtffjKYp8Rhy4VBuSUx3e8ELOdIe+ok1XhrnA5xeMVlPwEADO4jp R09BcYQzA6Fjjo9/yGx1n0TEeYBHfLCggBZlgC66J1XNDIjWc2rNiLUCZh/kZAmlGbG2+3tNFlR DgmMeOKxwPO73VbuJbcMwx7sBNu9TzH2DMVLg8OHzWD6KNg8pYrwVugk1xNjvOroSLqN96uA== User-Agent: NeoMutt/20240201 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[076.ne.jp:s=dkim]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fair.moe]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.76.192.0/19, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[076.ne.jp:+] X-Rspamd-Queue-Id: 4WzGYg2l6vz4cWd --kgtpmmdnfkuvdnbq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024=E5=B9=B409=E6=9C=8804=E6=97=A5 08:43, the silly David Chisnall clai= med to have said: > On 4 Sep 2024, at 07:35, lain. wrote: > >=20 > > About C developers being in decline, I actually disagree with that. > > I have seen younger generations getting interested in C the more they > > get overwhelmed by the amount of new languages to chose from. >=20 > This does not reflect my experience in hiring, the data I=E2=80=99ve seen= from a major tech company, or the trends in open source contributions. >=20 > It is far easier to hire C++ developers than C developers. This shift sta= rted a bit after C++11 was released and has continued.=20 >=20 > This trend is reflected in open source. Here is the OpenHub graph: >=20 > https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontribu= tors&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_nam= e%255B%255D=3D-1&language_name%255B%255D=3D-1&language_name%255B%255D=3D-1&= commit=3DUpdate >=20 > This shows the number of open source contributors making contributions in= C or C++ over the past decade. You=E2=80=99ll see that there are now more = than three times as many C++ developers as C contributing to open source pr= ojects (I=E2=80=99m ignoring the last few months where it looks as if C pro= grammers all gave up and went home, I presume there=E2=80=99s an error in t= he underlying data). >=20 > For Rust, the situation is more complicated. Hiring good Rust developers = is harder than hiring C developers (there are no Rust developers with ten y= ears experience because the language isn=E2=80=99t that old, and even thoug= h a lot of people are learning it, there=E2=80=99s a lot of inertia). This = changes a lot when you look at the open source ecosystem because the fact t= hat Rust is new and came from the open-source world skews the people who le= arn it towards open source and towards wanting to practice the language tha= t they=E2=80=99ve learned. Here=E2=80=99s the same graph with Rust added: >=20 > https://openhub.net/languages/compare?utf8=3D%E2%9C%93&measure=3Dcontribu= tors&language_name%255B%255D=3Dc&language_name%255B%255D=3Dcpp&language_nam= e%255B%255D=3Drust&language_name%255B%255D=3D-1&commit=3DUpdate >=20 > Note that there are still fewer Rust developers than C, but they=E2=80=99= re increasing and they tend to be more enthusiastic contributors. >=20 > David When looking at recruitment alone, I'm aware that nobody wants to learn something companies don't hire, and in return, nobody wants to hire something nobody is learning. It's an infinite feedback loop. When looking at Github repositories alone, C declining would be correct. However, Github is not the only Git hosting platform, and C might be more thriving on other platforms. My observation is that C developers today are either "dissidents" against modern languages, or lone wolf programmers, or developers going their own way (DGTOW?), or homebrew developers for retro consoles, or Unix greybeards, or people doing embedded programming for a living. There is data, and so there is nuance. --=20 lain. PGP public key: https://fair.moe/lain.asc --kgtpmmdnfkuvdnbq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRjt7VGft6AEgroX7Nt5cCzjCJFhwUCZtgglQAKCRBt5cCzjCJF h4IZAPoCodYuvWN18VLp2kjKKa3MqDVScrupcnR+1wWaJE8x4wD/TCfr41P6V0qq ip+qba0S4kdYY/RPnTAMp6B1VQUAtwI= =8J4I -----END PGP SIGNATURE----- --kgtpmmdnfkuvdnbq-- From nobody Wed Sep 4 09:09:09 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 4WzGs05gxZz5TTM6 for ; Wed, 04 Sep 2024 09:09:24 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4WzGry5kJWz4g3K for ; Wed, 4 Sep 2024 09:09:22 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=ER5aDvGX; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id E709C4E670; Wed, 04 Sep 2024 19:09:09 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725440949; bh=UJEUvqaqZLs/GhgTvLnYrrOE1qk=; h=Comments:Received:From:Comments:Message-ID:Date:To:Subject: Content-Disposition:In-Reply-To:References:Mime-Version: Content-Type; b=ER5aDvGXTzd6GqLhHol7AZClxZ1oBJ/AkmnvEMBlLXkbjwyO519mGPTGCJwx8pj0V rv3JE7HjoJThsKRWAm9Rwxtz2EvJw0tZpoOkvQrlU96fgLeDY+Ox5ajxL9KLFUHScd VhL57y20YKxnmxYbKCA9UiyygVYYs1F/Z+wa3wJg=wa3wJg= Comments: QMDA 0.3a Received: (qmail 49832 invoked by uid 1001); 4 Sep 2024 09:09:09 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> Date: Wed, 4 Sep 2024 09:09:09 +0000 To: freebsd-hackers@freebsd.org Subject: Rust: kernel vs user-space Content-Disposition: inline In-Reply-To: <7533543.20240904114624@yahoo.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> 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: text/plain; charset=utf-8 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.71 / 15.00]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.86)[-0.860]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.26)[-0.255]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[emu.st]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4WzGry5kJWz4g3K I hesitate to step into this discussion but is it worth making the distinction between Rust in the kernel and Rust in user-space? I can see the argument for introducing a "safer" language into the kernel and there are very few candidates available: perhaps only Rust, C++ and Zig. Clearly if that step is to be made, it probably should pick one language and run with it. That's one discussion. As for user-space, I find the rationale for Rust as the one-true-language-after-C far less compelling as many CLIs and server programs can just as well be written in more accessible languages such as go or perl or java or... Frankly I no longer write any CLI or server code in C even after decades of doing so because the trade-off between development costs and performance is far less compelling in user-space. If my once-a-week invocation of a command requires a bit more memory and CPU than one written in C, is that really important compared to how much easier the command is to maintain and enhance? Point being, on the matter of introducing Rust to FreeBSD, I think the distinction between kernel and user-space is worth keeping in mind as they are quite different problems. Mark. From nobody Wed Sep 4 09:25:37 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 4WzHCx6sLvz5TW7m for ; Wed, 04 Sep 2024 09:25:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4WzHCx64gZz4jv0; Wed, 4 Sep 2024 09:25:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725441949; 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=5cbwOJ2WZX/8e/PvEU783MmW5/ckrM5wTIp9SKaXICg=; b=cK2EcrCdDjiywZPRViUTXVsEOiJjrBfqu2zgyfMfMae0KPBjIxoKniPXNBilp/sEbTkA+Y Hg8gS/AFcfuU9GhDRtGTfnW9ej8r2NVusRWmPG/nLYnTv4EY+F2v9U0GWc/nvPmeprVODa Nnv3vdYkYXcZu/XlqHYhRisIdMghmq0jm511Kwn28NUyDcmXRxHMTBoHBEhLcOoGKqALb3 qp++ak24HjdG2MClGIp/TRM0A0UQvGEIkJ6ANspqWQA/o96ocRdFRBq7QZUjeOQPDo4pi1 8h382jdSnC+oTXf/I8i4MfsKAk8Fw3lC6Wpe/dDvKq3JR4dXixXmll78HxCsxw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725441949; a=rsa-sha256; cv=none; b=EHTu2+uhw/EFUx/F5sWjGmz+n03ADfDpL3XwxA7xqwty95K+v5RpSvWudqSLr9VXhRskHd AAeJTgFoP0LxzkEar1PSZZGAvTMo6YL7RxC37MOph6OIAIzcEgqFQEr6WQbAHAI++mSh2E olSjxa8BAYvpEhf51azv428d0WjQDAzLJc+aaEy9g231mNayl8viLnt1lclMdiz4AgSxrT UrBMZjwWTh3USVrkTYCL1uQmdD4f7z7zkJxg2oFvlL2PuLQR+kP5HcyaqXHbt1jc+M3myo XPAE7x4PRS8xwbW5F5kf3bYDxbefMi8E6H6o2gN+IRCyNAo9a9o/pqJ5shS4fQ== 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=1725441949; 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=5cbwOJ2WZX/8e/PvEU783MmW5/ckrM5wTIp9SKaXICg=; b=R+83rk3/SCxFvUF11w1QVeDBptbphjVY3Dabl5i/7g2UkmQapK9AUDYURTHHYrSL8wc3Gf wy+VS7N+Y7wxtCKSkolx5BojHB4TgVFIvc/6sBRgrj9YcSfTSJuq+iwoW+l3KNf7/Kn/g6 qHJaGE8C0w5oOheDtgfEITmn44aAT2WplPfX0MgeTMf6wvK0LeWeFjLO8HrV+vx6n9eeH/ 1mkIEACFHr6WaWXtgLgEyjkCX93sA2kQv082o+5f+gin3wYMdqDceBXXh0v1uGazMtppUQ DFuJo8zSgFfguWGZ5o8YjoqQsEWtVzsGnXBmUgFsPJHbgtDNGRTtD7LDAtWEjw== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzHCx5TDyzK2R; Wed, 4 Sep 2024 09:25:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 05CE150FB; Wed, 04 Sep 2024 10:25:48 +0100 (BST) From: David Chisnall Message-Id: <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_32030E2D-359B-47E5-99E7-236CC5A6E140" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Rust: kernel vs user-space Date: Wed, 4 Sep 2024 10:25:37 +0100 In-Reply-To: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> Cc: freebsd-hackers@freebsd.org To: Mark Delany References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_32030E2D-359B-47E5-99E7-236CC5A6E140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 4 Sep 2024, at 10:09, Mark Delany wrote: >=20 > As for user-space, I find the rationale for Rust as the = one-true-language-after-C far less > compelling as many CLIs and server programs can just as well be = written in more accessible > languages such as go or perl or java or=E2=80=A6 For personal projects, I=E2=80=99ve been using Sol3, which is a C++ = library that (via a lot of slightly terrifying metaprogramming) makes it = trivial to expose bindings to Lua. It=E2=80=99s fantastic for wrapping = some low-level things in C++ and then writing all of the important logic = in Lua. Given that C++ and Lua are already in the base system, I=E2=80=99= d love to see something like this used. I did some prototyping a few years ago exposing Dear ImGui with the = ImTui back end to Lua, for writing rich TUIs (with a little kqueue-based = event loop so that I/O could all be exposed to Lua as non-blocking = coroutines and you could yield to the scheduler to write cooperatively = multithreaded Lua). My hope was that ImTui and ImGui-WS would be = upstreamed to Dear ImGui so that it would be easy to write TUIs that = could also give X11 / Wayland GUIs or in-browser GUIs that you could = tunnel over SSH. Unfortunately, the author of ImTui and ImGUI-WS moved = on to writing llama.cpp and so I gave up hoping that this would happen. = I could tidy up the core bits if anyone is interested though. There are lots of control-plane things that I=E2=80=99d love to see = written mostly in Lua, David --Apple-Mail=_32030E2D-359B-47E5-99E7-236CC5A6E140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 4 Sep 2024, = at 10:09, Mark Delany <x9k@charlie.emu.st> = wrote:

As for user-space, I find the rationale for = Rust as the one-true-language-after-C far less
compelling as many CLIs and server programs can just as = well be written in more accessible
languages such as go or = perl or java or=E2=80=A6

For= personal projects, I=E2=80=99ve been using Sol3, which is a C++ library = that (via a lot of slightly terrifying metaprogramming) makes it trivial = to expose bindings to Lua.  It=E2=80=99s fantastic for wrapping = some low-level things in C++ and then writing all of the important logic = in Lua.  Given that C++ and Lua are already in the base system, = I=E2=80=99d love to see something like this used.

I = did some prototyping a few years ago exposing Dear ImGui with the ImTui = back end to Lua, for writing rich TUIs (with a little kqueue-based event = loop so that I/O could all be exposed to Lua as non-blocking coroutines = and you could yield to the scheduler to write cooperatively = multithreaded Lua).  My hope was that ImTui and ImGui-WS would be = upstreamed to Dear ImGui so that it would be easy to write TUIs that = could also give X11 / Wayland GUIs or in-browser GUIs that you could = tunnel over SSH.  Unfortunately, the author of ImTui and ImGUI-WS = moved on to writing llama.cpp and so I gave up hoping that this would = happen.  I could tidy up the core bits if anyone is interested = though.

There are lots of control-plane things = that I=E2=80=99d love to see written mostly in = Lua,

David

= --Apple-Mail=_32030E2D-359B-47E5-99E7-236CC5A6E140-- From nobody Wed Sep 4 09:52:32 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 4WzHpz2GLfz5TYSL for ; Wed, 04 Sep 2024 09:52:43 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4WzHpw1clNz4qKL for ; Wed, 4 Sep 2024 09:52:38 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=qiQakN1c; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id D1B634E670; Wed, 04 Sep 2024 19:52:32 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725443552; bh=J1zreO0Vh+sNf4tzPgq/idHv86U=; h=Comments:Received:From:Comments:Message-ID:Date:Mime-Version: Content-Type:References:Content-Disposition:In-Reply-To:To: Subject; b=qiQakN1culMe3I2XrEhsqpUdqc7r+J+4L1xq1JXTTqWwEddUBIcLy8o5mRUoutD20 b2FgNDMTu1df/U+RQfG3nkEJlpK5gUbNl3ukdOdR34445O4E0Z00tZ7yb5NIURh+qG SCpCizwDrO2zI+dIMu6IL1Ydrp51V7Van3Bi9qiI=Bi9qiI= Comments: QMDA 0.3a Received: (qmail 50151 invoked by uid 1001); 4 Sep 2024 09:52:32 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> Date: Wed, 4 Sep 2024 09:52:32 +0000 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: text/plain; charset=utf-8 References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> Content-Disposition: inline In-Reply-To: <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> To: freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space X-Spamd-Bar: / X-Spamd-Result: default: False [-0.61 / 15.00]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.85)[-0.851]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; NEURAL_HAM_LONG(-0.17)[-0.168]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[emu.st]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4WzHpw1clNz4qKL On 04Sep24, David Chisnall apparently wrote: > There are lots of control-plane things that I'd love to see > written mostly in Lua, It was remiss of me to not mention Lua given that it's already in the project. Yet another language which could make life easier, more productive and more accessible in user-land. I'm not suggesting for an instant that any of these programs need rewriting, but one could imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, programs which take a lot of user input and do a lot of data manipulation but aren't super-critical on the performance front) were written in a more accessible language, then it might attract new developers without disenfranchising the core C developers. Mark. From nobody Wed Sep 4 10:36:23 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 4WzJlK6xdnz5TcXv for ; Wed, 04 Sep 2024 10:34:37 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic310-57.consmr.mail.ir2.yahoo.com (sonic310-57.consmr.mail.ir2.yahoo.com [77.238.177.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzJlK4NrLz4trg for ; Wed, 4 Sep 2024 10:34:37 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725446075; bh=r+AUg4gCjcbVKKTlDdux4xft4ofqBypGOegjIbnJO/U=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject:Reply-To; b=GtbwEpuqlg0S2Pn0TE0hsGFGaeu2L4PXF50IltqVhJx26o3rY6mCqgPoRn8JjBZPcIURZvyBc6oxIhTaPDqn29IHq7wapwupPMEGIQhR8NXO0STaaVAPAlecLa/CJry4j559LzS/0XD4ELMh5qaYIsD4sXlyKLLSlaQaw8Qo6Lf3QxKPIlG7Z7Y1c5q/FyPrtuU3RqBFXFIc9RmxEhoc9IuVrywXNh5krHrJ2cWouL6yUBI2wQdwmSYucsyMuWXZbqUuYZPSZ2HYe3NMfcJAkgThYWLs+PRVVGOO+0EZf/lqAyvKnNdfD5PfxHhJ4h6kjokiHvlR78Jn+qlM1slwBA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725446075; bh=oE8eKsbPoz11B9SbvKWkvZ2ir/NnsznFx+MlebnM7wY=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=I/VnWk8vpgJRaVV8IKtVF9YDOUcRaJswb6Y8GpeCt+fowlDw8xPnlUFFXx3b4tAEMPU1nAP3vZXIFbC+fM2w7cTY8f//C4Y/Ms6L4v8QLDCL9dCU56N/AwXN3vUSwPVVmU39x/UMbRPqUNABxGXdxaFzHX69ZaQJ2xey91Z8yd1MSZzGVBlyy3yEITlCEhuRrNAkH9jwS/RaaVqgXy6hvLm+khaGKzDvW0lsLD0JrFHQcjTDDHvP5NjZ2xBoktDdMz5oFGgllKso+WixWNsXV+GOYWY+yHdhkbeVdwsUJA2iMBrDL7toMPxgm/cf8hqM86BvyOP9Gf5B7P3p3b0qUA== X-YMail-OSG: fI2LUq4VM1lYCd1YjaxZ64jYf3cIGkWspfeLx91JsRpcXCd.j5kkUNaGnxOSFlW zKcWd1ApiaWdzGnwcGBYNe3F46428MjJ8w0PM7UxyB_dpnUKaUG3FEhpDd37aWpSLiDioxlGJ25m WMoStXAEo58dEL95dC4bF1Y_ozQQ3s6VL5GMGZ1.e4mFwtZiQsQ7icLRqasyp.iphm201dWs7CEO 6vZhIGKVl2UySxT5uZ2W7yTqB4Lnr6So3YDjk871_IAzONxkgCuyKPGaDkLLwCvVAI80m_rWo.TY YG2r4Fo6HxsfZjNx0knPe0QtHtlfYQVHwf4ndOePKRFaCh2iMJbuzvmO_hh0omT880BuxdDvmQv6 NQmqCFFYyU83Ls_4IJjcHPsqlgBChZDsEbQkIY4V7at8U.ANoGrObrE3CuRDIqyUfQwXJ4V_.5j0 Kazn4HSshEI31TTf3PZ5MSFVxbdQdtbdxPVeE.zBk3DcmClVaItSXQDCngeLGh07xh0jVK9Adaej Z8LJiAs.AgVWyRb661m_C2SUJL9ch7vXvMVV9oxwb5pD5DfAaxeqAXbWc8u1wnHks8Tg3JGTMQqC 7cY7KQdWf6e64NVGhj5JOxVGe5ILvPMDPyFuIjjat8SDh9cnWpKhB6hVNETF_.hC.4uXrs8p9UQZ 2WwlRS7Fa4VA3zdomct9RKyE6b20OKzOJFv.XomO_A5WO4GOEKbrXCy3kx05Tn8Z8ArAyyeHh0H3 Uv461mgybbM5FdS.kvYXuRLVtUx4AeAZrlPEswHZ8Ih5Yak7FZi85D8XY132YiWJCYpnCWG6v9GN mfA.3WazHYwBLtbHVNKAnVrz5vvoXbX4_FkaP7CZagD_GkfwKd7jTaUVjxkBfcTp1J8KKIzFcUwu zculo.StbOlMIIgCWsub94NvIE2VebLcn4mKSJW8BJkeJnOyeGoXs2OfRv1uIEwsAX1D6Nl2cyeG d49qGXkwgpRdjj1jF_LDN55nyc.C5djtjJtFJAnnJNX4NACfzzM1y4WglHMzP_38YoJ8qXF9b7j_ 88sBNn979NPNPbxB8xmYNULFAtNLJX.J2ZLpdeoE9OAHy7MOVBByuS3oZWmsQCsOpnjKXxPBp4K4 dslNMzhwG7lS_nw9FRWNM.CyeFUfceaaWCDzJWYYX4iwcpK5b1Vm7w5c8LUVtHzE0qzLW257xoLC BoB23DJPLX_UdSsq53318LynAiH7luU3F55J1NrRMuSfvVQwHWn2I9tST24c4wXOoAxciAUL6EaJ qWLBwwFLaLBs.N1_bcze54ju4PGq7W6Ruk62bj2nSnIOARMV82m6HEFmz7NT4JZaW5sKx03loRF0 SZaGngKhh.s.FubKFs7tt5V1aHUb1nvFAGAEjxBKNu711Rm0FJ0iOKqyWDVTrIBX5TOIBqY3mAkw lFpulZPlMoHCg1ZB4.eRXJtFRWjXUOlRQgIn77NkIs0V4NCmIYWBWGD5X_or.hpRnXItdZ00RE60 ws_TzXdPaKkX1S7woJ8Ek9t0mkOgwW0WsdcDnxflNGgCQgVixJ1RtujrGVpe9fz4iVukbiHeokSz KzXZ4QZPqHFiEKrcqSuNzbv5pL65gCDkAhoERCG3CnCbmZlYOE2hHfWlWzMYS8SjGAiwU942x4qy or0uf_2PYxoXrEfMAQjcRGDZLyjjxaEF5.WeXzqR.mkt9yc4vsBCt2mU7FLveooQvlsrleLMhVtv DSQWW7yuHIXPp1TDYx7VGlJ8DyQC1.3JHBc2QhKc1nJA_pSOkRpjafcASmfSVdmk2PGwpFeQ4ifH uYPko5FuJZsJtJMlMVsH2rtqg_fDhA0uh.UqjvJqXnQMpGQFV8xs2ZIMj2Nc40sa2EPGKcimTSG9 DfYieoPMqGBU3cl5xLjtyqlJBFTd5wGUxPLyyYwDcg57r1FzNkdtghOvUKBqFjhWhXV8gbWkwKfD skr776_1YguJqZ2OWTv_szVxWWOtSUHrwWowImAMhHQHhMu4qPFib5D.tNQ2MieVX3VXtGvUiGcb lE3q1a_L5M5o_rTy1Vv35jTP8yNm3fHG7WOGrQra2UY2zkBwKObrS9X6gv7jrAAeCrXEs8z55d_G 1QeqoOfxeRMkoMnIkFXiCPVKJEmfSsNQAGll0cM.OWZYnSE4h10BXcE2UDu_YXvMjZpqQwGavsP8 KGqTICvtmyIidTkVTCx.3EESq.bAtFc5pANU_Bq7kCF8c X-Sonic-MF: X-Sonic-ID: df88246f-1490-4419-b9bc-84a2a65f9c53 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Wed, 4 Sep 2024 10:34:35 +0000 Received: by hermes--production-ir2-6664f499fc-fnmws (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51d0a597773566f8c16298bb6a50c768; Wed, 04 Sep 2024 10:34:32 +0000 (UTC) Date: Wed, 4 Sep 2024 13:36:23 +0300 From: Anthony Pankov Message-ID: <27925916.20240904133623@yahoo.com> To: Rob Norris , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) In-Reply-To: References: <202409031131.483BVdax004602@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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Queue-Id: 4WzJlK4NrLz4trg Hello Rob, > What I actually want though is high-quality tools to make the kind of > problems I need to solve easier for my puny human brain to manage. Rust > is an approach to solving some of these kinds of problems. Other > approaches exist, have existed, and will exist in the future. I'm interested in your opinion. Do the tools like PROMELA-SPIN used for some (critical) part of a C-sourced project will give more correctness and less error prone compared to rewriting project in Rust? Is there an actual possibility to make such a tools integral part of project? Wednesday, September 4, 2024, 11:03:13 AM, you wrote: > On 03.09.2024 11:31, Poul-Henning Kamp wrote: >> But first and foremost: There has to be a good enough reason. > This is a near-enough hook for me to hitch a couple of thoughts on to :) > I work on ZFS, primarily on Linux with slowly increasing amounts on > FreeBSD too. By a long way, the kind of work that is the slowest and > most complicated is around complex locking sequences across multiple > threads. In most of these, getting it wrong leads to some kind of data > corruption that is usually impossible to track down. > The appeal of Rust for me, as for many, is that there are ways to encode > those kind of sequencing rules into the type system so that the compiler > can tell you where you got it wrong. But, I don't actually want Rust _as > such_. I like it a lot, I've written useful programs in Rust over the > last decade, and I'd be perfectly happy to use it in kernel and > filesystem development if it was available. > What I actually want though is high-quality tools to make the kind of > problems I need to solve easier for my puny human brain to manage. Rust > is an approach to solving some of these kinds of problems. Other > approaches exist, have existed, and will exist in the future. > This is mostly aimed at the "C is totally fine" crowd. I like C, and I'm > pretty good at it, but it absolutely not good enough for many kinds of > software. Frankly, I find "just get better at C" to be the most > infuratingly facile "argument" against Rust. > (And I would _love_ to get better at C. If substantially better C tools > are out there (on whatever axis you like to measure that on), then > they're either not visible to me, or they're not usable or > well-integrated enough to be in my standard kit). > There's plenty of plausible reasons not to include Rust in the base > system, many of them being discussed on this list, and I'm learning a > lot reading along. Just please don't pretend the problems it's trying to > solve aren't real. > Cheers, > Rob. > -- > Rob Norris | robn.au | robn@despairlabs.com > Working on OpenZFS, because there's a lot of data out there and it'd be > nice not to lose any of it. -- Best regards, Anthony Pankov From nobody Wed Sep 4 10:56:12 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 4WzKDS2GPtz5TfQ9 for ; Wed, 04 Sep 2024 10:56:24 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4WzKDS0Kd0z4xqG for ; Wed, 4 Sep 2024 10:56:23 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 23931 invoked by uid 89); 4 Sep 2024 10:56:23 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO smtpclient.apple) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 4 Sep 2024 10:56:23 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jan Knepper 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 (1.0) Subject: Re: Rust: kernel vs user-space Date: Wed, 4 Sep 2024 06:56:12 -0400 Message-Id: <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> Cc: freebsd-hackers@freebsd.org In-Reply-To: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> To: Mark Delany X-Mailer: iPhone Mail (21C62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4WzKDS0Kd0z4xqG D www.dlang.org ManiaC++ Jan Knepper > On Sep 4, 2024, at 05:09, Mark Delany wrote: >=20 > =EF=BB=BFI hesitate to step into this discussion but is it worth making th= e distinction between > Rust in the kernel and Rust in user-space? >=20 > I can see the argument for introducing a "safer" language into the kernel a= nd there are > very few candidates available: perhaps only Rust, C++ and Zig. Clearly if t= hat step is to > be made, it probably should pick one language and run with it. >=20 > That's one discussion. >=20 > As for user-space, I find the rationale for Rust as the one-true-language-= after-C far less > compelling as many CLIs and server programs can just as well be written in= more accessible > languages such as go or perl or java or... >=20 > Frankly I no longer write any CLI or server code in C even after decades o= f doing so > because the trade-off between development costs and performance is far les= s compelling in > user-space. If my once-a-week invocation of a command requires a bit more m= emory and CPU > than one written in C, is that really important compared to how much easie= r the command is > to maintain and enhance? >=20 > Point being, on the matter of introducing Rust to FreeBSD, I think the dis= tinction between > kernel and user-space is worth keeping in mind as they are quite different= problems. >=20 >=20 > Mark. >=20 From nobody Wed Sep 4 13:57:34 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 4WzPFb6cWdz5TxTB for ; Wed, 04 Sep 2024 13:57:39 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch [185.70.43.166]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzPFb4BCgz45b6 for ; Wed, 4 Sep 2024 13:57:39 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725458257; x=1725717457; bh=ahJ3hNf++qwFbAYzrRCaITzLjGJwN/+pnUAvOcif5NY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=PgvW5aIaVC2/zxc7a/t1/ADlAjT1ixe+Z/v4jHT9vyADHqtsGuL384BYEXC6tvrhf TCAFoS/UMF4rmV+SWkva6q7pFGsk0zaKwNoelhjKX/5+ZUW31t/DKGfCk6Mcs4NKwC uOAZaiLMKt9+CE7FIpt2HHHRH9swZYRLECG1j5J0KZaxj8Q8l0HXok/I9VrcCjo/J1 LnB2bkBPCRcR3SEivG2Iq7OYGBULBMX8gdRDa7uHYfBRNRaMWl+7Tja2FOkUNViGN5 h8oKZBju41fIKjMrvRZgxI/BwpOAy5wLWK2CY9L/I13fLpTl8EHBv8u2UQQKm5cLmp S86WhRQI+r7vA== Date: Wed, 04 Sep 2024 13:57:34 +0000 To: Anthony Pankov From: fvalasiad Cc: Rob Norris , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: In-Reply-To: <27925916.20240904133623@yahoo.com> References: <202409031131.483BVdax004602@critter.freebsd.dk> <27925916.20240904133623@yahoo.com> Feedback-ID: 78761413:user:proton X-Pm-Message-ID: d15bed8b7edc75e435c5f1816dc05dc7a9b019e4 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Queue-Id: 4WzPFb4BCgz45b6 Being one of the young C developers you are referring to lain, right out of= uni from some southern european country, allow me to share my experience. The introductory class that teaches basic programming is done in C. Basic c= oncepts like if statements, loops, structs, up to malloc(3) and free(3). The backlog of students for that class is the biggest in the entire univers= ity, amounting to 700 people like 2 years ago, mind you the uni takes about= 100 students per year. Additionally, in 3rd and 4th year where students pick fields of study, the = one I followed about hardware had barely 6 students in my year. Funnily, we= all found a job in the field before we even left uni. Most students, if not because of inadequacy, seem to not choose C. I also haven't seem to met anyone entering the Rust cult either, they sure = exist but they are also a minority. While this is alarming, I don't find it impossible for this to come back ar= ound if demand rises in parallel with the paycheck offered for the job. Mon= ey is a great motivator especially if you are struggling to make ends meet. Given how the funding situation goes with FOSS projects though, things aren= 't great as you all know! Again, that's a completely biased experience cherry picked from a single co= mputer science department in some small country, so take this with a mouthf= ul of salt. Fotis. =20 On Wednesday, September 4th, 2024 at 1:34 PM, Anthony Pankov wrote: > Hello Rob, >=20 > > What I actually want though is high-quality tools to make the kind of > > problems I need to solve easier for my puny human brain to manage. Rust > > is an approach to solving some of these kinds of problems. Other > > approaches exist, have existed, and will exist in the future. >=20 >=20 > I'm interested in your opinion. Do the tools like PROMELA-SPIN used for s= ome (critical) part of a C-sourced project will give more correctness and l= ess error prone compared to rewriting project in Rust? > Is there an actual possibility to make such a tools integral part of proj= ect? >=20 > Wednesday, September 4, 2024, 11:03:13 AM, you wrote: >=20 > > On 03.09.2024 11:31, Poul-Henning Kamp wrote: > >=20 > > > But first and foremost: There has to be a good enough reason. >=20 > > This is a near-enough hook for me to hitch a couple of thoughts on to := ) >=20 > > I work on ZFS, primarily on Linux with slowly increasing amounts on > > FreeBSD too. By a long way, the kind of work that is the slowest and > > most complicated is around complex locking sequences across multiple > > threads. In most of these, getting it wrong leads to some kind of data > > corruption that is usually impossible to track down. >=20 > > The appeal of Rust for me, as for many, is that there are ways to encod= e > > those kind of sequencing rules into the type system so that the compile= r > > can tell you where you got it wrong. But, I don't actually want Rust as > > such. I like it a lot, I've written useful programs in Rust over the > > last decade, and I'd be perfectly happy to use it in kernel and > > filesystem development if it was available. >=20 > > What I actually want though is high-quality tools to make the kind of > > problems I need to solve easier for my puny human brain to manage. Rust > > is an approach to solving some of these kinds of problems. Other > > approaches exist, have existed, and will exist in the future. >=20 > > This is mostly aimed at the "C is totally fine" crowd. I like C, and I'= m > > pretty good at it, but it absolutely not good enough for many kinds of > > software. Frankly, I find "just get better at C" to be the most > > infuratingly facile "argument" against Rust. >=20 > > (And I would love to get better at C. If substantially better C tools > > are out there (on whatever axis you like to measure that on), then > > they're either not visible to me, or they're not usable or > > well-integrated enough to be in my standard kit). >=20 > > There's plenty of plausible reasons not to include Rust in the base > > system, many of them being discussed on this list, and I'm learning a > > lot reading along. Just please don't pretend the problems it's trying t= o > > solve aren't real. >=20 > > Cheers, > > Rob. >=20 > > -- > > Rob Norris | robn.au | robn@despairlabs.com >=20 > > Working on OpenZFS, because there's a lot of data out there and it'd be > > nice not to lose any of it. >=20 >=20 >=20 >=20 > -- > Best regards, > Anthony Pankov From nobody Wed Sep 4 14:37:50 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 4WzQ81497vz5V1nt for ; Wed, 04 Sep 2024 14:37:53 +0000 (UTC) (envelope-from se@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 4WzQ813grZz4Cs5; Wed, 4 Sep 2024 14:37:53 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725460673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=J8URwS7rwwhC3VdqLxtP6Am5b5Q3iL/rneitlmCC6KM=; b=tDvIr3hJtqArnkCWvKpUbEzasYJ8pmkwBGswpXXRonmGbVa1bP2roAfdEbK14qXVW2mD/q yyK4x7WhTRUT2iwhkINr1dsddrNS/mGSsmbbAbEku9SujWyQKXhq83TZe0pdT0wRdWxPmu L9SX4qx5aMkhB7fffwqKo2t74B54gsiHYT6vrNJqZ5H7iJSGBS9yHsNx8cWz2q4W9ZnI0J DRNY+besD1t4+Trf4LgjaqQWvV7lf1YTsGyEsxrJa4kud7Gf5TmFpyB+JDEbFNjWSc80sZ TjPk3dWXfxiysU/eEeUiYv3+F4C+EmvoGwPJhCVFKYovs1XOnSfzao90jz+YHQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725460673; a=rsa-sha256; cv=none; b=tlMpqhOLvB7yYtBZpvgIJt/H+K2n5AjbCWTw7b14OQSnLxHny8cPLJMZOOioSmiazMrzNL F3G+qwL78ATvCEEEJwd/+7l/jvF429ZLhV+tRrzEZGNT1eUwYh2PoT2CTFSdxaZXWuYluU vLiqNScva/uAeuEicAUjwkz/qaF0A0HhZnuRcaCy8BoPRm0AO/czBgtxKkJkQMvtI0TAcN FNE6xld3WaXqwEFZ3Wp362YcerIWUgDKh3OVTK0SEQgQEMRr5Tp3lSzR06GG5lWP0MtfB7 ZBE9QOtwaLF93p+1sosqkd5Leyb7i30JxjrTu6CZTlt9hPvLCwkpeVpkHGDmxg== 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=1725460673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=J8URwS7rwwhC3VdqLxtP6Am5b5Q3iL/rneitlmCC6KM=; b=tSu04jJTxKhx4u77XCqfWX1QNlSnbLMux2BuBYBIXdp3+du1FKt5QWPE93wj7uBXEr7g4m 8oYl4IzbOQqDiYfjmB1uqBlc4UG3f8wg8TnAxl6JxI4Rp2hHj5S+9JJ49murFEPkJUSHLP 1/9UGffYSzTe+fUw8V/qXLtuCZcCxnYc3Xu54b73TKHLpaMDrqnGPekVoDVdqpPQ/Sm3HN vB3UwccTwGFwMCC8cLMFwKcHcozaqvKNI+TdqNoJ7uXjCFs43Pn0Fdq5EOahuZwLZzVIKC 7UaI95FQMq8j1FQIvRnMs8hs1G+uv2o1FU0o1JNJAwtbBHcuOXDV3fXXPziayg== Received: from [192.168.119.159] (p5dc83c4d.dip0.t-ipconnect.de [93.200.60.77]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzQ810spmzQs6; Wed, 4 Sep 2024 14:37:52 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Wed, 4 Sep 2024 16:37:50 +0200 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 User-Agent: Mozilla Thunderbird From: Stefan Esser Subject: Re: Rust: kernel vs user-space To: freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> Content-Language: de-DE, en-US Autocrypt: addr=se@FreeBSD.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNJ1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPsLAlAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9B BQkTLNNOAAoJEEfrte9a/fVEV1oH/jt+SjRqTHci6d1LiFDfbY0E2rfobZw5BhcQuCqxahS7 pcE1oLpUaoqWYPHslxhGTl7QSD2twMWcHLonZ1lgTJluMZqgTX9uvqEYDUtiH6G+IF7Qacat eUsAvwdycItPOr3p7WBt8U54GbnQdxpSUQ0OpD4twy7KAt/MPNLofVQSEea5DNQOH2dXILrf iRsNfFPsfTASOUXOTRyTYwm6Ys76LIdL9GA2iR5qw8G43FB02fiX76WQSjg+yKN9iP9racGg Pc8qkSPwHJr0s3OwJC4ndbCuSiaXddDbgOvdrqfSO0XCjo3ylyEBhmMVMpwkj8pLCKVGS73n Ncs6OujZXAzOwE0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAcLAhgQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9BBQkT LNNOABQJEEfrte9a/fVECRBH67XvWv31RCrvCACY7fjahcGj/57peFu0oIb4X9X78H6mgrAZ D5HCCCb2vWdNtSDTYQoYnKP2Fz9RUG8ETT9a6CtymYqQc72/dzjJmakRTlbYhliKJDZXGAYU g34VirGXCjYgWH7l+0CupOtt55R/ASnrnXX9R/7PLO+akObn9Cz/bNBnIbYnTjLNs7GMMQL4 uNSyqIByQ3LVsVDaCq3408fYKC0dtlv2VNQQzcXXwOgecwpS2UeqMflrSA7UfPh15WgkpnrN AnKCtS66eU1w2kTCsVEjGQEgLI5pP1HMNRHjnHncAFSpOfs1EZn0MfhiyB+4T+lrccGI8EZu ay791Tx4QdDKkdZGaV9A In-Reply-To: <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 04.09.24 um 11:52 schrieb Mark Delany: > On 04Sep24, David Chisnall apparently wrote: > >> There are lots of control-plane things that I'd love to see >> written mostly in Lua, > > It was remiss of me to not mention Lua given that it's already in the project. > > Yet another language which could make life easier, more productive and more accessible in > user-land. > > I'm not suggesting for an instant that any of these programs need rewriting, but one could > imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, programs which > take a lot of user input and do a lot of data manipulation but aren't super-critical on > the performance front) were written in a more accessible language, then it might attract > new developers without disenfranchising the core C developers. Here is ldconfig in LUA, written more than 2 years ago, for example: https://github.com/stesser/ldconfig/blob/main/ldconfig.lua From nobody Wed Sep 4 14:58:59 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 4WzQcZ08Vmz5V3sC for ; Wed, 04 Sep 2024 14:59:10 +0000 (UTC) (envelope-from me@levitati.ng) Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzQcY3sR9z4Kf9 for ; Wed, 4 Sep 2024 14:59:09 +0000 (UTC) (envelope-from me@levitati.ng) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: a=rsa-sha256; b=N5UovgCPV72ek7dF9Y7JTerK/TBiWiNxONig3ayMakc5BPM1X7ukPoPbMqGAUW4iFxumvOfLlRpFcg27BaDVm4gtRfTrGck2f27YaH0DF9V0tfSMQmN7db2CttZ0JjgAEnmnVycD0ZGNP/NBV+Oougq02Nv76T6WJvt7WsTYNC4OXrbFRI7VZcTmaDqOvnwOsn2aL2Ctzq/uxHgBxXldOHddFz+UVelcnwGfCXsIDUYskosz+ZQSy8dCHnU2k6rBKWaNcg++pFkKcIW7ub9lit0RJt8+Dhew7tIgvuB+j6+2hhr/u7MICJIEypCqcVKO2YHfZXML+OdY9cvrHFMdQw==; s=purelymail1; d=levitati.ng; v=1; bh=vCnyquQuNjQFlfoDq2ywB3osc2eaG/wwEjE8KHCuPkY=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=PS4oDZvV15YChGcRNYg+rfagrjX512mjj84oIhCrnQNVsJEQOQPLAamgXtv6vZ+5pMHIYTgugqhsvaTyI84cvdhXM/uZP22E+cMZ0poSnAFS0dW67mgVunwUrhrE4QUUwR2WozJ/2US87dKfqZUxqSJq9CfqhHiLUhwJKvaQwliBSF5W5jXMVQoWqVIh4nL3dcShfMGW+RYEejXm/J8/E7rf7eixL8NOmD56wl8sif3MgrV7edCb6nOlsoWRrkqn+O1ePgOJ/LpcRjaUpr3WncY+tOHVqtoFGRB1USM4z5iOXI3cphIOM7orXQXee2cepKGUS2/++oC1/Kz03XK+kQ==; s=purelymail1; d=purelymail.com; v=1; bh=vCnyquQuNjQFlfoDq2ywB3osc2eaG/wwEjE8KHCuPkY=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 25799:4744:null:purelymail X-Pm-Original-To: freebsd-hackers@freebsd.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPA id -2075742915; Wed, 04 Sep 2024 14:58:59 +0000 (UTC) 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 Date: Wed, 04 Sep 2024 16:58:59 +0200 From: "Rein Fernhout (Levitating)" To: Mark Delany Cc: freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space In-Reply-To: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> User-Agent: Purely Mail via Roundcube/1.6.8 Message-ID: <2bc0f51f110c943c58a1ce34d6725e9c@purelymail.com> X-Sender: me@levitati.ng Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4WzQcY3sR9z4Kf9 On 2024-09-04 11:09, Mark Delany wrote: > As for user-space, I find the rationale for Rust as the > one-true-language-after-C far less > compelling as many CLIs and server programs can just as well be written > in more accessible > languages such as go or perl or java or... > > Frankly I no longer write any CLI or server code in C even after > decades of doing so > because the trade-off between development costs and performance is far > less compelling in > user-space. If my once-a-week invocation of a command requires a bit > more memory and CPU > than one written in C, is that really important compared to how much > easier the command is > to maintain and enhance? I actually prefer Rust for CLI programs these days. The Clap argument parser allows you to parse command line arguments, with generated help and about pages, and autocomplete for various shells, which also supports autocompleting hostnames and the likes, all just by defining a structure.[0] Rust can also use libc directly or bind to other C libraries and has a very strong standard library in general. Otherwise I would personally reach for Ruby or Python. [0]: https://docs.rs/clap/latest/clap/_derive/index.html From nobody Wed Sep 4 15:21:24 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 4WzR6g0BNGz5V60M for ; Wed, 04 Sep 2024 15:21:47 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzR6f4cDmz4N79; Wed, 4 Sep 2024 15:21:46 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 484FLdUi029896; Wed, 4 Sep 2024 16:21:39 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 484FLYda065929; Wed, 4 Sep 2024 16:21:34 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Rust: kernel vs user-space From: Bob Bishop In-Reply-To: Date: Wed, 4 Sep 2024 16:21:24 +0100 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> To: Stefan Esser X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4WzR6f4cDmz4N79 Hi, > On 4 Sep 2024, at 15:37, Stefan Esser wrote: >=20 > Am 04.09.24 um 11:52 schrieb Mark Delany: >> On 04Sep24, David Chisnall apparently wrote: >>> There are lots of control-plane things that I'd love to see >>> written mostly in Lua, >> It was remiss of me to not mention Lua given that it's already in the = project. >> Yet another language which could make life easier, more productive = and more accessible in >> user-land. >> I'm not suggesting for an instant that any of these programs need = rewriting, but one could >> imagine that if commands like ifconfig, route, arp, ndp, ipfw (that = is, programs which >> take a lot of user input and do a lot of data manipulation but aren't = super-critical on >> the performance front) were written in a more accessible language, = then it might attract >> new developers without disenfranchising the core C developers. >=20 > Here is ldconfig in LUA, written more than 2 years ago, for example: >=20 > https://github.com/stesser/ldconfig/blob/main/ldconfig.lua And this is better than C because ...? (Asking for a friend :-) -- Bob Bishop rb@gid.co.uk From nobody Wed Sep 4 15:37:44 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 4WzRTM1bymz5V6vn for ; Wed, 04 Sep 2024 15:37:59 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzRTL6BBVz4PYM for ; Wed, 4 Sep 2024 15:37:58 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-e1ce8a675f7so3145177276.3 for ; Wed, 04 Sep 2024 08:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725464278; x=1726069078; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c9+PLqvmrMd16rO5T1u0YD5rsvn+fKlm6S8BuycBMJM=; b=E6DF5plYhisw5Hz2T/YlhEhYcsjCl50yZomuWwE/NTGrrvZfQllwtwzTd04e1Mvq9t BYKiETmsc4FSOFwGVgtvG/PuBde0CiKNxPbSdiQo8lJKZ3WUnSXvFwLnM0nIEWA42AIk MG8yCUfZxQ2w8EPyp9SMDOgdkFArE/TzOv6u5rNyqcKTXObIB2LhDMQBQkVCWeaE9xbi W3AsdICngjDU+Os+f8jnfTTw7G9L+tOw/UgAcc3+9kEN1Nefz3133YbQ9PKjCog8iEqb fis0+6rheHiuhbQbxLdhQPGDYBhAQVqelm4cRRbi4BR9VLgUXXN/q+RX/E4GVhWR5Tu1 +ncQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725464278; x=1726069078; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c9+PLqvmrMd16rO5T1u0YD5rsvn+fKlm6S8BuycBMJM=; b=AQRW4uCd2ehjYjs0HQ/925JQVHoyEcrqmYYqm59PMJBSo1/SMNLgFa7s81YFozKVti oWtrCtfKHGHiyfZb2PC+YV+zMc39PE0w+6+wz8YvpjHpL5bAb2JLYL5Ju8EbzlJrHvBW gVYrFw304xS0oxHMe2x0aZIVTsA/o7Fpn8wgm77DsrAcbhFkwCqWTuDML+OXyVzAfg+S nL14IopID7rtoBpXU7aHh+g28XMA5pr3EKgEPZ8NvBIcnOFfvLNbSapBtPfqeqaIwrih rBCzFz2bsEdy+cUQLpORb3NAq35dR1kK8286DMl2E5VFyFarRDYqt3xb0cZ0DbuO34DJ hRkg== X-Gm-Message-State: AOJu0Yz+rIbOV/c0hlqb+qhbblOdM73/e7QPWF6OG8O4ffa5VvD2G9Br r4XdoULLp7Q8XlphrZAxgkaSvnvpPAeHFFOelMKrzKTAgCJ1HhFyEZiD0FK+p95IOWnQpZTHLpQ = X-Google-Smtp-Source: AGHT+IFVg83Iyvw5xX5j6ZhksJHtMjPeK99IzL4Kj8uw4xRyi9sUhlMurNMpZYCgwRCPkXjcf+7L4A== X-Received: by 2002:a05:6902:1791:b0:e1d:1434:98a4 with SMTP id 3f1490d57ef6-e1d1434abfamr2152461276.9.1725464277615; Wed, 04 Sep 2024 08:37:57 -0700 (PDT) Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com. [209.85.128.177]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e1a626e4954sm2572706276.51.2024.09.04.08.37.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Sep 2024 08:37:57 -0700 (PDT) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-6d47d860fc4so40850457b3.3 for ; Wed, 04 Sep 2024 08:37:56 -0700 (PDT) X-Received: by 2002:a05:690c:7a1:b0:618:2381:2404 with SMTP id 00721157ae682-6d40fc1d278mr220850177b3.44.1725464276670; Wed, 04 Sep 2024 08:37:56 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> In-Reply-To: <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> From: Tomek CEDRO Date: Wed, 4 Sep 2024 17:37:44 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Rust: kernel vs user-space To: Mark Delany Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WzRTL6BBVz4PYM On Wed, Sep 4, 2024 at 11:53=E2=80=AFAM Mark Delany wr= ote: > On 04Sep24, David Chisnall apparently wrote: > > There are lots of control-plane things that I'd love to see > > written mostly in Lua, > It was remiss of me to not mention Lua given that it's already in the pro= ject. > Yet another language which could make life easier, more productive and mo= re accessible in > user-land. > > I'm not suggesting for an instant that any of these programs need rewriti= ng, but one could > imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, p= rograms which > take a lot of user input and do a lot of data manipulation but aren't sup= er-critical on > the performance front) were written in a more accessible language, then i= t might attract > new developers without disenfranchising the core C developers. Just do not change ifconfig to ip (and other basic networking tools) like Linux did :D :D :D --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Sep 4 16:00:12 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 4WzRzJ697Yz5V8H4 for ; Wed, 04 Sep 2024 16:00:28 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzRzJ1qkrz4XKX for ; Wed, 4 Sep 2024 16:00:28 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=IhnEG3T6; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::b2b) smtp.mailfrom=tomek@cedro.info Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-e1ce8a675f7so3174587276.3 for ; Wed, 04 Sep 2024 09:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725465627; x=1726070427; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+ELEwV9ImeqQA+QEHWg9bNmAZ1gVJPtNlQ/3jSbOe7U=; b=IhnEG3T6x7N1TvyFw6uoPz3qEFB0N6ZQPPVSrcIDeUojQk8F76t7mDESrKFQmCFTLJ 0wN9RQOcYTgU52t3nI1W5lfi9Y+byH1bUatZJPnlopoEeJFmsHCVcixBR2VjrNWAzrYP WwX5CRVh/9PWqFbMsjcr3DSocepOaxzaE5beM7k8OrYGI3SBz778cx/rGoCa6Qhr6vqP HSCoNTKZqmviKGNynPfdazC5ugC+6+e9AulsPx6jUotiIE+l2TUug19a7U2ig+QKCRvC bgWK0wnWWvxnr2wk7x6qupiVPujsRcMF1e4ikSF//kH/+W5moNm3kY8rzIrghuRLPJVT m1dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725465627; x=1726070427; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+ELEwV9ImeqQA+QEHWg9bNmAZ1gVJPtNlQ/3jSbOe7U=; b=H4laQYSFs90tmFyPsbq2VYrKC63HgrERCVRP3pnxIOGNBD3clRGd5mwfTRCg3+B3n2 EvRno2Onaqun6lRGMWpviITyIkPtPyRWBWxP3yfykC08nzGAaSa3bDPd9olbJOJQtrma Fp7dqdEOc4J9q45IfoW6TLSAiI+d9rat/8oM89LpW5nexXIaAilaEK3aIYphb+lW7vQf qdFBDWn2kRkMOV7Apcv1prPZsw9B95HDkL5o9TmPn553dYBoorWxP5B979RGUi25Ezp0 /VAUx2Renu55mVQefXWcUDuCPlOgcB1xQzbHK1KN6cf/I3uoqOW6O4D2OwlsHkwmK3ye /neQ== X-Gm-Message-State: AOJu0YwAqnMqO0YTL3o6jC+TQ899jsOMRhkjTsdyfTBLx+w+oPMHmFQ4 8hehc78sPKEcIDJuAh0kdoQ/kUa/G575SrCZJTsJoZkuzLQT1zqf9qNlgc6BT/r2qQOVaNS4h3w = X-Google-Smtp-Source: AGHT+IGxaJdFIWEv5gtrMWl6uSfBrCTX0+zWrTYS7jufbkV/MgDdOynbGQvfkgYy7RSHeyQAX2h6sg== X-Received: by 2002:a25:ce50:0:b0:e1a:8026:e71b with SMTP id 3f1490d57ef6-e1a8026e893mr16092573276.54.1725465627011; Wed, 04 Sep 2024 09:00:27 -0700 (PDT) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e1a90f32470sm1840812276.58.2024.09.04.09.00.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Sep 2024 09:00:26 -0700 (PDT) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-6d6891012d5so35614757b3.2 for ; Wed, 04 Sep 2024 09:00:26 -0700 (PDT) X-Received: by 2002:a05:690c:660c:b0:6d7:3c0d:3ab2 with SMTP id 00721157ae682-6d73c0d3fe6mr132271977b3.6.1725465625904; Wed, 04 Sep 2024 09:00:25 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> From: Tomek CEDRO Date: Wed, 4 Sep 2024 18:00:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from,209.85.128.176:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4WzRzJ1qkrz4XKX On Tue, Sep 3, 2024 at 5:32=E2=80=AFPM Poul-Henning Kamp wrote: > What is FreeBSD ? FreeBSD is a Free and Open-Source Unix Operating Systems with a coherent and self sufficient base (/usr/src -compiler-> /) that can expand userland with various Open-Source applications (/usr/ports -compiler-> /usr/local). FreeBSD "base" is a well defined common starting point after installation always the same among different installations and platforms. It can be used to bootstrap OS over network (diskless install), hard drive, USB, any many others. From here custom userland can be loaded and used. But the starting point is well defined and common everywhere. I call this self-compatibility. I like this design and would not change it. Look at Linux for instance - each distribution is different, even update of the same version of distribution can differ in functionality. Not to mention kernel update will most likely break userland due to driver API changes. Most problems on FreeBSD that are related to incompatible modules (i.e. vbox or drm) are caused because those modules are designed for Linux and adapted here. I call this self-incompatiblity. The difference in design is better seen on a resulting mobile phones - all iOS (BSD based) devices have the same base that can be extended with userland applications, while all Android (Linux based) devices are completely different (base applications, bundled applications, icons, even keyboard layout, etc). Another example - you have zombie apocalypse and some disks with source code for various operating systems - which systems would you be able to build and run offline from those backups? Have a good day folks :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Sep 4 16:01:49 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 4WzS1Z15P3z5V8bw for ; Wed, 04 Sep 2024 16:02:26 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4WzS1Y6N2tz4ZJf for ; Wed, 4 Sep 2024 16:02:25 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 65640 invoked by uid 89); 4 Sep 2024 16:02:25 -0000 Received: from unknown (HELO smtpclient.apple) (jan@digitaldaemon.com@166.196.113.1) by digitaldaemon.com with SMTP; 4 Sep 2024 16:02:25 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jan Knepper 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 (1.0) Subject: Re: Rust: kernel vs user-space Date: Wed, 4 Sep 2024 12:01:49 -0400 Message-Id: References: Cc: Stefan Esser , freebsd-hackers@freebsd.org In-Reply-To: To: Bob Bishop X-Mailer: iPhone Mail (21C62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4WzS1Y6N2tz4ZJf Yeah=E2=80=A6 I second that question=E2=80=A6 (Not asking for a friend=E2=80=A6 :-) ) ManiaC++ Jan Knepper > On Sep 4, 2024, at 11:22, Bob Bishop wrote: >=20 > =EF=BB=BFHi, >=20 >> On 4 Sep 2024, at 15:37, Stefan Esser wrote: >>=20 >>> Am 04.09.24 um 11:52 schrieb Mark Delany: >>> On 04Sep24, David Chisnall apparently wrote: >>>> There are lots of control-plane things that I'd love to see >>>> written mostly in Lua, >>> It was remiss of me to not mention Lua given that it's already in the pr= oject. >>> Yet another language which could make life easier, more productive and m= ore accessible in >>> user-land. >>> I'm not suggesting for an instant that any of these programs need rewrit= ing, but one could >>> imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, p= rograms which >>> take a lot of user input and do a lot of data manipulation but aren't su= per-critical on >>> the performance front) were written in a more accessible language, then i= t might attract >>> new developers without disenfranchising the core C developers. >>=20 >> Here is ldconfig in LUA, written more than 2 years ago, for example: >>=20 >> https://github.com/stesser/ldconfig/blob/main/ldconfig.lua >=20 > And this is better than C because ...? >=20 > (Asking for a friend :-) >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 From nobody Wed Sep 4 16:42:37 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 4WzSvz4ZQvz5VDWJ for ; Wed, 04 Sep 2024 16:42:39 +0000 (UTC) (envelope-from se@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 4WzSvz450Rz4jnQ; Wed, 4 Sep 2024 16:42:39 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725468159; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RU5t5cTR4+ztl/tUXGIbeaNcqg7Rto1gVadmStG9OYY=; b=S5av0Q9/WLU2zCcu8SfOUYD3HMkTkM2grsBDBxNjvSjcY7zXX+tM7bdiOERflIE3AIjkIP KP/tABfn/Pt9hJckA2LDpPLtFhJBFx/UcjMlnz6moX+y71LE1QT9PZD3dXSrjAN8TiMCSe P68d3x7KJdVfTt/RlfetDYuGDTIvSpG+p2QE6kTD+EdGQfnYiFNVwwA0tbazTDskhZc0a0 mwVrh4z8i4/lnM+kQ3j8ERLOcRlhuZBqVcOx0owv/hw/fNpR5UZNLfwKHR9UbuMYLm2M+d alPU4Fp4hamWz+8VdC/eydcSbsrww60Fa3Jq0MoAOp0cnNbOMT+pFEvRBEDvkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725468159; a=rsa-sha256; cv=none; b=vkOOOSxaB3xc3WsTpVcjaQxp7yHwabEkcC7e0yVI4PSmxY5vUjzvVJd99bLoQ9aArh8UNU Mil/b6HIP7NBx5mKH4HvrT/Xa7AGinsk0mJ9xw/i7upbdwNyvOIABH/ujNjCriSxZexxy5 YD+Er9gEgFTXf9Nli82bQ5h+0d4slCjfStS1cdZiUSTyBkXF539TkH64txaQBfQ5EWVMCl ZT7yTQYbJUY0W9gK3LevYPgjivVmzWCimuYAw5Omsqw0JWx581xa08Bry3Dvjtv8bWcgGR lAmQQ/QZGf6A6y52xwE6dv9jsRy018/5sZlD6h/FzqGuBecvDxTqUJXJGI+bSQ== 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=1725468159; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RU5t5cTR4+ztl/tUXGIbeaNcqg7Rto1gVadmStG9OYY=; b=ezwj32xH0mtvOqZrPYbjZxyPtEDITYRq/Srix/amSwv3t+WaR9Xd/Z4ErPXzOWff4jzCsv dYeYdchLC1na47uHt39yRhi+pJT8LqFvEEQcmB8Zjqv2XP5RA0PjztqvuU9KgRvy2FvBZP 2qiI2xWqWEtbB9UmnzZijBHKTJlGJG0ZocZ7iAkxKvvTVwx2rMkX8rmtYjZFuPJAxDI24r L4QVo5PcA3dB1dQAF4lDpjOSD+dwN2ezshCGWf1O9YMOXno/cc9IRoaW+e3TLgkvpEf0l+ KD8mtMaxVkrb/uaNRV1sH3BRkZWdN3cDDXXWOj/+94gERHaref26gCnTZiIREw== Received: from [192.168.119.159] (p5dc83c4d.dip0.t-ipconnect.de [93.200.60.77]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzSvz0ZdtzRWf; Wed, 4 Sep 2024 16:42:38 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> Date: Wed, 4 Sep 2024 18:42:37 +0200 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 User-Agent: Mozilla Thunderbird From: Stefan Esser Subject: Re: Rust: kernel vs user-space To: Bob Bishop Cc: "freebsd-hackers@freebsd.org" References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> Content-Language: de-DE, en-US Autocrypt: addr=se@FreeBSD.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNJ1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPsLAlAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9B BQkTLNNOAAoJEEfrte9a/fVEV1oH/jt+SjRqTHci6d1LiFDfbY0E2rfobZw5BhcQuCqxahS7 pcE1oLpUaoqWYPHslxhGTl7QSD2twMWcHLonZ1lgTJluMZqgTX9uvqEYDUtiH6G+IF7Qacat eUsAvwdycItPOr3p7WBt8U54GbnQdxpSUQ0OpD4twy7KAt/MPNLofVQSEea5DNQOH2dXILrf iRsNfFPsfTASOUXOTRyTYwm6Ys76LIdL9GA2iR5qw8G43FB02fiX76WQSjg+yKN9iP9racGg Pc8qkSPwHJr0s3OwJC4ndbCuSiaXddDbgOvdrqfSO0XCjo3ylyEBhmMVMpwkj8pLCKVGS73n Ncs6OujZXAzOwE0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAcLAhgQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9BBQkT LNNOABQJEEfrte9a/fVECRBH67XvWv31RCrvCACY7fjahcGj/57peFu0oIb4X9X78H6mgrAZ D5HCCCb2vWdNtSDTYQoYnKP2Fz9RUG8ETT9a6CtymYqQc72/dzjJmakRTlbYhliKJDZXGAYU g34VirGXCjYgWH7l+0CupOtt55R/ASnrnXX9R/7PLO+akObn9Cz/bNBnIbYnTjLNs7GMMQL4 uNSyqIByQ3LVsVDaCq3408fYKC0dtlv2VNQQzcXXwOgecwpS2UeqMflrSA7UfPh15WgkpnrN AnKCtS66eU1w2kTCsVEjGQEgLI5pP1HMNRHjnHncAFSpOfs1EZn0MfhiyB+4T+lrccGI8EZu ay791Tx4QdDKkdZGaV9A In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 04.09.24 um 17:21 schrieb Bob Bishop: > Hi, > >> On 4 Sep 2024, at 15:37, Stefan Esser wrote: >> >> Am 04.09.24 um 11:52 schrieb Mark Delany: >>> On 04Sep24, David Chisnall apparently wrote: >>>> There are lots of control-plane things that I'd love to see >>>> written mostly in Lua, >>> It was remiss of me to not mention Lua given that it's already in the project. >>> Yet another language which could make life easier, more productive and more accessible in >>> user-land. >>> I'm not suggesting for an instant that any of these programs need rewriting, but one could >>> imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, programs which >>> take a lot of user input and do a lot of data manipulation but aren't super-critical on >>> the performance front) were written in a more accessible language, then it might attract >>> new developers without disenfranchising the core C developers. >> >> Here is ldconfig in LUA, written more than 2 years ago, for example: >> >> https://github.com/stesser/ldconfig/blob/main/ldconfig.lua > > And this is better than C because ...? > > (Asking for a friend :-) There had been a request for an architecture independent implementation that works on all FreeBSD releases and architectures. The LUA run-time has been available in FreeBSD for a long time, and it is a stable platform suitable for the implementation of commands that operate on text and might take advantage of features like associative storage. It is a "safe" implementation since memory is automatically managed, which reduces the risk of memory management errors (but we have to trust the LUA interpreter to be free of such issues, instead). I have not made this version available for review (but instead updated the C version to work with hints files of either byte order). But this code is much simpler than the C version it replaces, and it could easily be extended to, e.g., prepare hints files in chroot environments or in images prepared for an architecture with a (possibly) different byte order. And it is not only independent of the byte order and portable over all architectures, but also independent of the FreeBSD version. The LUA version is much shorter and easier to understand (if you know LUA), but one reason not to propose it for inclusion in FreeBSD is that there are many more developers that know how to work on the C version than on the LUA version. David and Mark have mentioned LUA, and there is little LUA code in the base system, currently (mostly the loader). I'd like to see LUA being used for more functionality that is not time critical, and since the LUA language has been very stable over time (other than many other interpreted languages), it is unlikely that a LUA script will not work on a later FreeBSD release (it only depends on a working flua and possibly some LUA include files). Anyway, this is off-topic for the discussion about rust, other than that LUA is a language that is not affected by many bugs that are typical for programs written in C. Best regards, STefan From nobody Wed Sep 4 19:52:43 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 4WzY7T6xCXz5VGl0 for ; Wed, 04 Sep 2024 19:52:53 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4WzY7R36dlz46wl for ; Wed, 4 Sep 2024 19:52:50 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=NNjQWw3v; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id 8738F4E670; Thu, 05 Sep 2024 05:52:43 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725479563; bh=ROL248zFHTe/Czq4lp0u9l8/xso=; h=Comments:Received:From:Comments:Message-ID:References: Content-Type:In-Reply-To:Content-Disposition:Date:To:Subject: Mime-Version; b=NNjQWw3vYCfN1ZqlmVsufMdl0vtgV0K5cxZKb2k9yJYSGq7H0uyBS4VdSNHDEZn2I SHej2EjrGsR3+K2lIPD16pugNcKqElCUSbeQzQUpVbFhqZ7APM8j2ASH8O7pjEhcyS LePZ+xGUCWzI3UcWabEu4lUeN1TQl8JNwhO+lKaU=O+lKaU= Comments: QMDA 0.3a Received: (qmail 54728 invoked by uid 1001); 4 Sep 2024 19:52:43 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725479563.495-0xfd6a7d@qmda.emu.st> References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <2bc0f51f110c943c58a1ce34d6725e9c@purelymail.com> Content-Type: text/plain; charset=utf-8 In-Reply-To: <2bc0f51f110c943c58a1ce34d6725e9c@purelymail.com> Content-Disposition: inline Date: Wed, 4 Sep 2024 19:52:43 +0000 To: freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space 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 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.65 / 15.00]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.85)[-0.851]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.20)[-0.200]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[emu.st]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4WzY7R36dlz46wl > And this is better than C because ...? I don't think any sane person suggests rewrites for rewrites sake, but it's the new code that needs to be created in the coming decades that is in question. The argument goes that C is becoming niche as the diminishing pool of developers approach retirement age. Wasn't that the most obvious trend of the last community survey conducted a while back? At some point finding C programmers may be as hard as finding COBOL programmers. The second argument goes that other languages are simply much more productive and that productivity is crucial for very large projects which need resourcing over decades. > Lua > Python > Ruby > Rust > Zig > dlang > go Above and beyond even deciding whether another language besides C is a good choice and above and beyond picking which one(s) are most suited, the underlying issue is that programming languages may continue to evolve and emerge and thus any choice today risks rapid obsolescence. It just may be that the programming industry is addicted to the siren call of the next shiny new thing and that there are no good language choices to be made for a project that spans decades. If you look at each of the decades that BSD code and its forebears have lived thru, each one produced a shiny new language with almost all of them now in rapid decline, extremely niche or defunct. So, any discussion like this is mostly about predicting the future, which I'm told is rather hard: - Is there a significant risk in not being able to source future C programmers? - Will a more popular/current language attract more contributors? - Is it possible to chose an appropriate language which will remain popular for decades? - Is it possible to define a set of criteria for when such decisions need to be made? - Is indecision a good option to see if next-gen programmers lose their addiction to shiny? Mark. From nobody Wed Sep 4 20:20:31 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 4WzYlX6WK1z5VK1f for ; Wed, 04 Sep 2024 20:20:40 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzYlX4NnPz4GrP for ; Wed, 4 Sep 2024 20:20:40 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725481233; x=1726147899; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=bOEDmG+Lk/vQ6LQOIJBfN6Q7GaEZj68ll6G+iyjzpKM=; b=Vx2ei0UJDVQnqY/Q1UQ5bTHwHhY5r77cVQzQ4/ePZQWtdWLH0WiT5/UKtFwM9XdZrXKtasit 6x2DQxermXnb3GZF0lV05FXoSR2jd5+7faV24n2EHZL272xek+uy/r2tnYURbFYVGAt7a3Hwq5 N0q4eW2Sj/3wqrTAO6hj8T/cYV8yARN4wM11sTmmGI1VnSSnUHDGl/OC7cSZBTKhtSrjeFNXt1 Gpub9E0nB6VliO7hfeHA1EsTxKlDpX/Yb4gIVTMYzwBbrHfW2A7XbYU91eT0A2J8LJeXK00RdN bOyj3/P87Oupm9Qeg29l2sdcUTxVzecLXkTSg2FCzcTCKbcg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725481233; x=1726147899; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=bOEDmG+Lk/vQ6LQOIJBfN6Q7GaEZj68ll6G+iyjzpKM=; b=5HCP7OcnTibC9+s5StAYwyIyDgW5xERpOA/8x8lM3ZoPNFtRdTdkBDb8xMgsJAarQhs3g6Cu EEVZSoTUC1zPDw== Date: Wed, 04 Sep 2024 22:20:31 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "Mark Delany" Cc: freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space Message-ID: <20240904202031.9bBKplcX@steffen%sdaoden.eu> In-Reply-To: <0.2.0-final-1725479563.495-0xfd6a7d@qmda.emu.st> References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <2bc0f51f110c943c58a1ce34d6725e9c@purelymail.com> <0.2.0-final-1725479563.495-0xfd6a7d@qmda.emu.st> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4WzYlX4NnPz4GrP 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 Mark Delany wrote in <0.2.0-final-1725479563.495-0xfd6a7d@qmda.emu.st>: |> And this is better than C because ...? ... |> Lua |> Python |> Ruby |> Rust |> Zig |> dlang |> go And have a look at nim-lang.org, eg https://nim-lang.org https://nim-lang.org/features.html it is pretty cool, and not so cryptic. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Sep 4 21:11:51 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 4WzZtr5kg3z5VPTT for ; Wed, 04 Sep 2024 21:12:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzZtr45P5z4ZRH for ; Wed, 4 Sep 2024 21:12:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-7cd8d2731d1so84460a12.3 for ; Wed, 04 Sep 2024 14:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725484323; x=1726089123; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1qZcfKz32GxSOW3sWJdrzAjo8oGfW515mKaCI2Q9zsE=; b=WrRFie/VjMax63dIYvX4dTPowOtTQW7cK/9l08IDZKg7TlG8dQO9oqAkkmpgaRh0zi CGsigKxBHqG7/c63n4P2w+tIr0tL9zR4m3yau05WWb/q5NV3Td2sJGUw8R+Dv1YdV5pt epS0iVzceGku/8KjKv+CW8zNYv/ctMM2EnnnhkAPrbvKC7E7WcYYs6otNpwsFEk10LV/ amSlD1wR7+zliLZ6+0tdkmIj6qH1hmsh9LsMaq7VYobqbMYRJss45xsid7oDXEOKpaKz GlYp2aqrJtzMj15oavw1klhOGaGBWY/Mqgzs+NL1hFl7xOSvs5tu43Q/f38diOuLPAUr OqQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725484323; x=1726089123; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1qZcfKz32GxSOW3sWJdrzAjo8oGfW515mKaCI2Q9zsE=; b=OZedr787eoBicRCEsTBwfcuXlmGKzACJHKNQMdK+/z1GNyK7D3TAZWuykiFyp4Sj9j mMMkOyO0EgtuqpMcuHgfzf33vA2r7PR7253Yw/G6SVcV1Zamen5KWGcfOZ+UC0jT/81l YA/mEGZ9xmta/Vq/RL+Uvx2HYC+nyJwN1oQuzeUmthOFi/NF8Ss0EQEleucLcVKd6SxF 5TrZB4BXFEDzXKjbTfNPJLslCZ3Nub8P+veftWmn1PbOdkNXmFgsTSA1xZjNsuNgoNno CPfzxqqBnApu/Wgwf7ZlhDgEtxqGELfDxFQlaTAC7PSs9/EVU26TZCSw4ibArA22BcVB lj4A== X-Forwarded-Encrypted: i=1; AJvYcCVnJCxJ1wimIk/Yxuod33eY4c2WFoO21dWnnH8do90eGmDjYwP5oqsG+NnOIqUvYM0eWUKCcVU7TDm+54eoZ5M=@freebsd.org X-Gm-Message-State: AOJu0YwC0rQ4kOwL4vkB++dorGKbRM0NmPZ453+lXP5aFxC/KIqI3M2v fKUIDYWeaX6TgTWK/HWaiiBWFzWI6F2wYQi06RFXVVbVIshY6Nybicm/ZDi2bihr4W0YnXElPTQ 4bSpfpGV3VXP/h42jzuyQD31kUqELt+rP3SS+tg== X-Google-Smtp-Source: AGHT+IGIelZQpVFGU/MXXaXqNcTLwEg3GNFM7U3eOD8szyBfO7WSXMt84WEdEd7ZPJQpYaoywa4a6vEvCYAfFMPeCKc= X-Received: by 2002:a17:90a:b116:b0:2c8:81b:e798 with SMTP id 98e67ed59e1d1-2d8973a57e7mr14544103a91.30.1725484322563; Wed, 04 Sep 2024 14:12:02 -0700 (PDT) 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 References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> In-Reply-To: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> From: Warner Losh Date: Wed, 4 Sep 2024 15:11:51 -0600 Message-ID: Subject: Re: Rust: kernel vs user-space To: Stefan Esser Cc: Bob Bishop , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000001cc4ae062151a08f" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WzZtr45P5z4ZRH --0000000000001cc4ae062151a08f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2024, 10:42=E2=80=AFAM Stefan Esser wrote: > Am 04.09.24 um 17:21 schrieb Bob Bishop: > > Hi, > > > >> On 4 Sep 2024, at 15:37, Stefan Esser wrote: > >> > >> Am 04.09.24 um 11:52 schrieb Mark Delany: > >>> On 04Sep24, David Chisnall apparently wrote: > >>>> There are lots of control-plane things that I'd love to see > >>>> written mostly in Lua, > >>> It was remiss of me to not mention Lua given that it's already in the > project. > >>> Yet another language which could make life easier, more productive an= d > more accessible in > >>> user-land. > >>> I'm not suggesting for an instant that any of these programs need > rewriting, but one could > >>> imagine that if commands like ifconfig, route, arp, ndp, ipfw (that > is, programs which > >>> take a lot of user input and do a lot of data manipulation but aren't > super-critical on > >>> the performance front) were written in a more accessible language, > then it might attract > >>> new developers without disenfranchising the core C developers. > >> > >> Here is ldconfig in LUA, written more than 2 years ago, for example: > >> > >> https://github.com/stesser/ldconfig/blob/main/ldconfig.lua > > > > And this is better than C because ...? > > > > (Asking for a friend :-) > > There had been a request for an architecture independent implementation > that works on all FreeBSD releases and architectures. > > The LUA run-time has been available in FreeBSD for a long time, and it > is a stable platform suitable for the implementation of commands that > operate on text and might take advantage of features like associative > storage. It is a "safe" implementation since memory is automatically > managed, which reduces the risk of memory management errors (but we > have to trust the LUA interpreter to be free of such issues, instead). > > I have not made this version available for review (but instead updated > the C version to work with hints files of either byte order). But this > code is much simpler than the C version it replaces, and it could easily > be extended to, e.g., prepare hints files in chroot environments or in > images prepared for an architecture with a (possibly) different byte orde= r. > > And it is not only independent of the byte order and portable over all > architectures, but also independent of the FreeBSD version. > > The LUA version is much shorter and easier to understand (if you know > LUA), but one reason not to propose it for inclusion in FreeBSD is that > there are many more developers that know how to work on the C version > than on the LUA version. > > David and Mark have mentioned LUA, and there is little LUA code in the > base system, currently (mostly the loader). I'd like to see LUA being > used for more functionality that is not time critical, and since the LUA > language has been very stable over time (other than many other interprete= d > languages), it is unlikely that a LUA script will not work on a later > FreeBSD release (it only depends on a working flua and possibly some > LUA include files). > I do most of my string processing code in lua these days. I think this reimplementaion makes sense: it helps in cross building. I have a config successor doodled out in lua... Warner Anyway, this is off-topic for the discussion about rust, other than > that LUA is a language that is not affected by many bugs that are > typical for programs written in C. > > Best regards, STefan > > --0000000000001cc4ae062151a08f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 4, 2024, 10:42=E2=80=AFAM Stefan Esser <= ;se@freebsd.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Am 04.09.24 um 17:21 schrieb Bob Bishop:
> Hi,
>
>> On 4 Sep 2024, at 15:37, Stefan Esser <se@FreeBSD.org> wrote= :
>>
>> Am 04.09.24 um 11:52 schrieb Mark Delany:
>>> On 04Sep24, David Chisnall apparently wrote:
>>>> There are lots of control-plane things that I'd love t= o see
>>>> written mostly in Lua,
>>> It was remiss of me to not mention Lua given that it's alr= eady in the project.
>>> Yet another language which could make life easier, more produc= tive and more accessible in
>>> user-land.
>>> I'm not suggesting for an instant that any of these progra= ms need rewriting, but one could
>>> imagine that if commands like ifconfig, route, arp, ndp, ipfw = (that is, programs which
>>> take a lot of user input and do a lot of data manipulation but= aren't super-critical on
>>> the performance front) were written in a more accessible langu= age, then it might attract
>>> new developers without disenfranchising the core C developers.=
>>
>> Here is ldconfig in LUA, written more than 2 years ago, for exampl= e:
>>
>> https://github.com/ste= sser/ldconfig/blob/main/ldconfig.lua
>
> And this is better than C because ...?
>
> (Asking for a friend :-)

There had been a request for an architecture independent implementation
that works on all FreeBSD releases and architectures.

The LUA run-time has been available in FreeBSD for a long time, and it
is a stable platform suitable for the implementation of commands that
operate on text and might take advantage of features like associative
storage. It is a "safe" implementation since memory is automatica= lly
managed, which reduces the risk of memory management errors (but we
have to trust the LUA interpreter to be free of such issues, instead).

I have not made this version available for review (but instead updated
the C version to work with hints files of either byte order). But this
code is much simpler than the C version it replaces, and it could easily be extended to, e.g., prepare hints files in chroot environments or in
images prepared for an architecture with a (possibly) different byte order.=

And it is not only independent of the byte order and portable over all
architectures, but also independent of the FreeBSD version.

The LUA version is much shorter and easier to understand (if you know
LUA), but one reason not to propose it for inclusion in FreeBSD is that
there are many more developers that know how to work on the C version
than on the LUA version.

David and Mark have mentioned LUA, and there is little LUA code in the
base system, currently (mostly the loader). I'd like to see LUA being used for more functionality that is not time critical, and since the LUA language has been very stable over time (other than many other interpreted<= br> languages), it is unlikely that a LUA script will not work on a later
FreeBSD release (it only depends on a working flua and possibly some
LUA include files).

I do most of my string processing code in lua these days= .

I think this reimpleme= ntaion makes sense: it helps in cross building.

=
I have a config successor doodled out in lua...

Warner

Anyway, this is off-topic for the discussion about rust, other than
that LUA is a language that is not affected by many bugs that are
typical for programs written in C.

Best regards, STefan

--0000000000001cc4ae062151a08f-- From nobody Wed Sep 4 21:48:10 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 4Wzbhm5HW7z5VRlx for ; Wed, 04 Sep 2024 21:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzbhm1r3Nz4g4V; Wed, 4 Sep 2024 21:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 484LmAPc025768; Thu, 5 Sep 2024 00:48:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 484LmAPc025768 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 484LmAhT025767; Thu, 5 Sep 2024 00:48:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Sep 2024 00:48:10 +0300 From: Konstantin Belousov To: Stefan Esser Cc: Bob Bishop , "freebsd-hackers@freebsd.org" Subject: Re: Rust: kernel vs user-space Message-ID: References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Wzbhm1r3Nz4g4V On Wed, Sep 04, 2024 at 06:42:37PM +0200, Stefan Esser wrote: > Am 04.09.24 um 17:21 schrieb Bob Bishop: > > Hi, > > > > > On 4 Sep 2024, at 15:37, Stefan Esser wrote: > > > > > > Am 04.09.24 um 11:52 schrieb Mark Delany: > > > > On 04Sep24, David Chisnall apparently wrote: > > > > > There are lots of control-plane things that I'd love to see > > > > > written mostly in Lua, > > > > It was remiss of me to not mention Lua given that it's already in the project. > > > > Yet another language which could make life easier, more productive and more accessible in > > > > user-land. > > > > I'm not suggesting for an instant that any of these programs need rewriting, but one could > > > > imagine that if commands like ifconfig, route, arp, ndp, ipfw (that is, programs which > > > > take a lot of user input and do a lot of data manipulation but aren't super-critical on > > > > the performance front) were written in a more accessible language, then it might attract > > > > new developers without disenfranchising the core C developers. > > > > > > Here is ldconfig in LUA, written more than 2 years ago, for example: > > > > > > https://github.com/stesser/ldconfig/blob/main/ldconfig.lua > > > > And this is better than C because ...? > > > > (Asking for a friend :-) > > There had been a request for an architecture independent implementation > that works on all FreeBSD releases and architectures. > > The LUA run-time has been available in FreeBSD for a long time, and it > is a stable platform suitable for the implementation of commands that > operate on text and might take advantage of features like associative > storage. It is a "safe" implementation since memory is automatically > managed, which reduces the risk of memory management errors (but we > have to trust the LUA interpreter to be free of such issues, instead). > > I have not made this version available for review (but instead updated > the C version to work with hints files of either byte order). But this > code is much simpler than the C version it replaces, and it could easily > be extended to, e.g., prepare hints files in chroot environments or in > images prepared for an architecture with a (possibly) different byte order. > > And it is not only independent of the byte order and portable over all > architectures, but also independent of the FreeBSD version. > > The LUA version is much shorter and easier to understand (if you know > LUA), but one reason not to propose it for inclusion in FreeBSD is that > there are many more developers that know how to work on the C version > than on the LUA version. I do not think that the population of developers who knows LUA vs C is significant for this example. But a different aspect is IMO much more important. The ldconfig utility is critical to fully configured multiuser FreeBSD state. Right now the utility depends on rtld and libc (ignoring the whole stuff at and below kernel). So any problem in either of rtld or libc which prevent ldconfig from run are critical. If rewritten in LUA, the utility has the same dependencies on rtld and libc, plus LUA runtime. Which, by itself, bring in /usr/libexec/flua: libm.so.5 => /lib/libm.so.5 (0x8010b1000) libedit.so.8 => /lib/libedit.so.8 (0x8010ed000) libprivateucl.so.1 => /usr/lib/libprivateucl.so.1 (0x801129000) libc.so.7 => /lib/libc.so.7 (0x80114f000) libtinfow.so.9 => /lib/libtinfow.so.9 (0x801552000) i.e. libm, terminfo, ucl (?), libedit. Then, flua runtime lives in /usr, while ldconfig is reasonably located in /sbin. There are other considerations than just the language accessibility when we consider the whole system. From nobody Wed Sep 4 22:15:22 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 4WzcHy3hBYz5VV1x for ; Wed, 04 Sep 2024 22:15:26 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzcHy1dkPz4r6w for ; Wed, 4 Sep 2024 22:15:26 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id lwFYsS9cx9TOUlyHdsbwEG; Wed, 04 Sep 2024 22:15:25 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id lyHbsjDAuKHV8lyHcsnL0F; Wed, 04 Sep 2024 22:15:25 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=XeEqz555 c=1 sm=1 tr=0 ts=66d8dbfd a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=EaEq8P2WXUwA:10 a=tBXV8v6mAAAA:8 a=WRJ6V7hQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=KYWzlS4NUXJUcX199jMA:9 a=CjuIK1q_8ugA:10 a=7GshWI0fspEqwfknWyrY:22 a=1zxpBTYGrzRwGOqLqlOP:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 95783395; Wed, 04 Sep 2024 15:15:22 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 63E0366; Wed, 04 Sep 2024 15:15:22 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jan Knepper cc: Mark Delany , freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space In-reply-to: <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> Comments: In-reply-to Jan Knepper message dated "Wed, 04 Sep 2024 06:56:12 -0400." 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: text/plain; charset=us-ascii Date: Wed, 04 Sep 2024 15:15:22 -0700 Message-Id: <20240904221522.63E0366@slippy.cwsent.com> X-CMAE-Envelope: MS4xfLZRe4OY5h8nwqm+lEBN32SaBLdcNUgb4zAVVAAqZy+kIRW74JJfRL8wZOq4ptn0ifWlSSYhq+cITNZqKpUo29V/S19ZbAOP3nza9HccdP7rZ4P74/dr TYEYZQ5bXNEzCWXAmQCXH4ClNb2FVyVV+bA/VnshuHDaG7EZ/PpfTsTaetDNi+rBz86jnNkun96AKdcmc2I7+aAjx3rX4u66GV4ruavnN5vlGMB5r9AqhpoA PTIp2HdVeJOu3KTD2Hc6+qYfcA4yBTTKhLIGrkl2iFs= X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4WzcHy1dkPz4r6w In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>, Jan Kneppe r writes: > D > > www.dlang.org The problem with D is data structure definitions need to also be mirrored (duplicated) in D. For example, when 64-bit inodes were implemented D failed to build and generate any code. The reason for this was ufs/ufs/inode.h now defined 64-bit inodes while the D representation as provided by the D language were still 32-bit. I had opened an issue with upstream regarding this. To this day they still haven't figured out how to implement 64-bit inodes on newer FreeBSD systems while maintaining 32-bit inode backward compatibility on older FreeBSD systems (as FreeBSD implemented this using ifunc). -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > > > ManiaC++ > Jan Knepper > > > On Sep 4, 2024, at 05:09, Mark Delany wrote: > >=20 > > =EF=BB=BFI hesitate to step into this discussion but is it worth making th= > e distinction between > > Rust in the kernel and Rust in user-space? > >=20 > > I can see the argument for introducing a "safer" language into the kernel a > = > nd there are > > very few candidates available: perhaps only Rust, C++ and Zig. Clearly if t > = > hat step is to > > be made, it probably should pick one language and run with it. > >=20 > > That's one discussion. > >=20 > > As for user-space, I find the rationale for Rust as the one-true-language-= > after-C far less > > compelling as many CLIs and server programs can just as well be written in= > more accessible > > languages such as go or perl or java or... > >=20 > > Frankly I no longer write any CLI or server code in C even after decades o= > f doing so > > because the trade-off between development costs and performance is far les= > s compelling in > > user-space. If my once-a-week invocation of a command requires a bit more m > = > emory and CPU > > than one written in C, is that really important compared to how much easie= > r the command is > > to maintain and enhance? > >=20 > > Point being, on the matter of introducing Rust to FreeBSD, I think the dis= > tinction between > > kernel and user-space is worth keeping in mind as they are quite different= > problems. > >=20 > >=20 > > Mark. > >=20 > > From nobody Wed Sep 4 22:40:47 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 4Wzcsf4Db0z5VWW8 for ; Wed, 04 Sep 2024 22:41:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzcsf2bPTz4t59 for ; Wed, 4 Sep 2024 22:41:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 484MemZF027435; Thu, 5 Sep 2024 01:40:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 484MemZF027435 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 484MelJA027434; Thu, 5 Sep 2024 01:40:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Sep 2024 01:40:47 +0300 From: Konstantin Belousov To: Cy Schubert Cc: Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space Message-ID: References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240904221522.63E0366@slippy.cwsent.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Wzcsf2bPTz4t59 On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>, Jan > Kneppe > r writes: > > D > > > > www.dlang.org > > The problem with D is data structure definitions need to also be mirrored > (duplicated) in D. For example, when 64-bit inodes were implemented D > failed to build and generate any code. The reason for this was > ufs/ufs/inode.h now defined 64-bit inodes while the D representation as > provided by the D language were still 32-bit. I had opened an issue with > upstream regarding this. To this day they still haven't figured out how to > implement 64-bit inodes on newer FreeBSD systems while maintaining 32-bit > inode backward compatibility on older FreeBSD systems (as FreeBSD > implemented this using ifunc). Rust is same. It still uses pre-ino64 bindings for both stdlib and libc. From nobody Wed Sep 4 23:43:31 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 4WzfFs5F4zz5Vv4S for ; Wed, 04 Sep 2024 23:43:45 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzfFs0z8Tz4JnT for ; Wed, 4 Sep 2024 23:43:45 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-500fbacd680so79977e0c.3 for ; Wed, 04 Sep 2024 16:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725493424; x=1726098224; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QGLnYDdLgVWvPt7MKrngIHIgOmnbBGCf4Z9GpyynhtQ=; b=VrXUtDuozL54iU6SEMjjUHZ7N96IaXIS7p34u0gawPAte+mUWT01XfdhEBqpJY5ZnY 4KhSY65tMWP4T/RZ8VxOqL5GA1JPHDK5tfNtVExqNpF8PJk81A7sq7gMTTawAe/UF1lC B0xrWGmiDBjC+gdUWPKStXgJroLz1gpJ6NDixOm8dqT7ZcZXX57FF7NSVBzVhlmpoBnY wsh32iCII7XGTe/pKnJNSFMi4weyS6JT2FYqnyLJi0Y+AbCpXGw8NEKuacTKE9kWnpKC aT8pf/O1vKbO/x+R8UVVz/VLL33lGYrvTjTHebfaq2oVmYYHspYZ4WtLx3rPsJbGF9rF A51g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725493424; x=1726098224; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QGLnYDdLgVWvPt7MKrngIHIgOmnbBGCf4Z9GpyynhtQ=; b=OsM1vkBEE+4ZsRZhTqnMPnGtcSfKTfo3oR01ptWQhxMYmlPZMzbyKl7ygX2rENwrNy XlPt0N8M7i/jAJyuIarQIiUQJUsAOjj4qH8qOCn1sQcqFNX+eWL4RKHNNUm+lJxZTqlh JjkZoMevfW1zE2B7Ck2rMMuENtql1ecOyu5NDk4opBc4BMmNbLO9sn4lJz02uRNo7H8B RLiqKE3H8BSBvwpjEe56xMcIZ/lNlwqYUpljOxp/YZsR1MyYvT7v4Dvv1sARafsZx62+ h5pioCiJ9H3Q27kF8y80SbXQO/TwQmyt3CnyBSg+Qu0C2k2KGR5n/9Wnhl3Vv0JFJXLB LIDw== X-Forwarded-Encrypted: i=1; AJvYcCUJBpNz7QWfEAbcgtygrxil7oZCIpo57xu4+sK3U2IfjGZ4maRh0mXnCwFn/ZcuryjfgHlb/RMBnk5Y8T7mPgk=@freebsd.org X-Gm-Message-State: AOJu0Yyxnm142p28phb5ghjLrlkQeuJZki0r9WF0n7y37cz2qc2LKqXB kJrUgIo7QR1H7+B2rb2EG6LiYLeT0UF/ldkxaYFiQfWlgmYSAdIsnLL9nBw1IHfcxbe4knr5wUz xP+yQ2Ip3gc1439yNrDFdRAdTi3g= X-Google-Smtp-Source: AGHT+IE2LflKbUyCfqcLlPrF4hcZGQGDJcckZeifooFCNwUB4aJpWzQSnHQcAVJRtBt+Z8IigC3fh7a6pjG83tBM1L4= X-Received: by 2002:a05:6122:8cf:b0:4ec:f8e4:e0bf with SMTP id 71dfb90a1353d-4ffe4a5c827mr26015958e0c.2.1725493423604; Wed, 04 Sep 2024 16:43:43 -0700 (PDT) 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 References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> In-Reply-To: From: Jacques Fourie Date: Wed, 4 Sep 2024 16:43:31 -0700 Message-ID: Subject: Re: Rust: kernel vs user-space To: Konstantin Belousov Cc: Cy Schubert , Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000938d87062153be08" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WzfFs0z8Tz4JnT --000000000000938d87062153be08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov wrote: > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>, > Jan > > Kneppe > > r writes: > > > D > > > > > > www.dlang.org > > > > The problem with D is data structure definitions need to also be > mirrored > > (duplicated) in D. For example, when 64-bit inodes were implemented D > > failed to build and generate any code. The reason for this was > > ufs/ufs/inode.h now defined 64-bit inodes while the D representation as > > provided by the D language were still 32-bit. I had opened an issue wit= h > > upstream regarding this. To this day they still haven't figured out how > to > > implement 64-bit inodes on newer FreeBSD systems while maintaining > 32-bit > > inode backward compatibility on older FreeBSD systems (as FreeBSD > > implemented this using ifunc). > > Rust is same. It still uses pre-ino64 bindings for both stdlib and libc. > Looking at the Rust libc bindings I see the following: https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4e= b132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8 https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4e= b132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5 Seems to have changed to 64 bit for FreeBSD 12 and up? --000000000000938d87062153be08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 4, 2024 at 3:41=E2=80=AFP= M Konstantin Belousov <kostikbel@= gmail.com> wrote:
On Wed, Sep 04, 2024 a= t 03:15:22PM -0700, Cy Schubert wrote:
> In message <78BC157F-6E30-49C4-931D-9EB539BD0322@d= igitaldaemon.com>, Jan
> Kneppe
> r writes:
> > D
> >
> > www.dlang.org
>
> The problem with D is data structure definitions need to also be mirro= red
> (duplicated) in D. For example, when 64-bit inodes were implemented D =
> failed to build and generate any code. The reason for this was
> ufs/ufs/inode.h now defined 64-bit inodes while the D representation a= s
> provided by the D language were still 32-bit. I had opened an issue wi= th
> upstream regarding this. To this day they still haven't figured ou= t how to
> implement 64-bit inodes on newer FreeBSD systems while maintaining 32-= bit
> inode backward compatibility on older FreeBSD systems (as FreeBSD
> implemented this using ifunc).

Rust is same.=C2=A0 It still uses pre-ino64 bindings for both stdlib and li= bc.

Looking at the Rust libc bindings I= see the following:

--000000000000938d87062153be08-- From nobody Wed Sep 4 23:59:15 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 4Wzfbr4Pn6z5VyW8 for ; Wed, 04 Sep 2024 23:59:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzfbq3XRnz4qGm; Wed, 4 Sep 2024 23:59:19 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725494357; x=1726161023; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=B5ibAIeHwouoSI9Uf/5q4DyTTnurzoquPO1x6QPXuEI=; b=lIGBk4oaZvRxc+omZrZgtIVxNEM//m1LTA8pA23oGUrd7hM/ECdluZ7dsS8vO0a5zdcyFSIN GmrpfoBVLr8mzQSO4+83oQIB6Do95EK5Yy8J0HolwxREF7fb85jqrLeKo1Yqo0PeTgCDZkj25m mwGmToMEwD/ZkIWiWd4YzJjrirUE02Ri4ybPPoR4LMr6YAi8SkTIuzJXct/6ytG1EPtIHp5AxV As0kasOlrp2W2jL8XC+uuM+t2wYlXAE18sDdaFEBiiOram0QdoMrnsZgYAtl5CgGW80C2pskk7 vtjhl0QyBfaQCqKlMrIp4WZKgOoL73hkXmTZxScMDySJRgJA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725494357; x=1726161023; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=B5ibAIeHwouoSI9Uf/5q4DyTTnurzoquPO1x6QPXuEI=; b=TKPngEUqM04XZo9FsT1s69tTL90ZO98SyHxvN0p+E9FYoXuaZTF1zzJ/m5Y1wBfOeQBJNdKi YG2LN7W1LN8CAQ== Date: Thu, 05 Sep 2024 01:59:15 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Konstantin Belousov Cc: Stefan Esser , Bob Bishop , "freebsd-hackers@freebsd.org" Subject: Re: Rust: kernel vs user-space Message-ID: <20240904235915.a1cYm7CJ@steffen%sdaoden.eu> In-Reply-To: References: <202409031532.483FW0If007252@critter.freebsd.dk> <7533543.20240904114624@yahoo.com> <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <65ED39B7-099F-43FD-9F53-68286125A65E@FreeBSD.org> <0.2.0-final-1725443552.800-0x2fa4dc@qmda.emu.st> <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4Wzfbq3XRnz4qGm 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 Konstantin Belousov wrote in : |On Wed, Sep 04, 2024 at 06:42:37PM +0200, Stefan Esser wrote: |> Am 04.09.24 um 17:21 schrieb Bob Bishop: |>>> On 4 Sep 2024, at 15:37, Stefan Esser wrote: |>>> Am 04.09.24 um 11:52 schrieb Mark Delany: |>>>> On 04Sep24, David Chisnall apparently wrote: |>>>>> There are lots of control-plane things that I'd love to see |>>>>> written mostly in Lua, |>>>> It was remiss of me to not mention Lua given that it's already \ |>>>> in the project. ... |>>> Here is ldconfig in LUA, written more than 2 years ago, for example: |>>> |>>> https://github.com/stesser/ldconfig/blob/main/ldconfig.lua ... |The ldconfig utility is critical to fully configured multiuser FreeBSD |state. Right now the utility depends on rtld and libc (ignoring the |whole stuff at and below kernel). So any problem in either of rtld or |libc which prevent ldconfig from run are critical. | |If rewritten in LUA, the utility has the same dependencies on rtld and |libc, plus LUA runtime. Which, by itself, bring in |/usr/libexec/flua: | libm.so.5 => /lib/libm.so.5 (0x8010b1000) | libedit.so.8 => /lib/libedit.so.8 (0x8010ed000) | libprivateucl.so.1 => /usr/lib/libprivateucl.so.1 (0x801129000) | libc.so.7 => /lib/libc.so.7 (0x80114f000) | libtinfow.so.9 => /lib/libtinfow.so.9 (0x801552000) |i.e. libm, terminfo, ucl (?), libedit. Then, flua runtime lives in /usr, |while ldconfig is reasonably located in /sbin. | |There are other considerations than just the language accessibility when |we consider the whole system. Compared to monsters like clang/llvm FreeBSD *could* very well include two lua binaries in maybe half a megabyte. For Linux lua includes two make targets, as i learned just now. FreeBSD NetBSD OpenBSD freebsd: $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE -I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc" ... Linux linux: linux-noreadline linux-noreadline: $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl" linux-readline: $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE" SYSLIBS="-Wl,-E -ldl -lreadline" --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Sep 5 00:11:13 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 4WzftC34wDz5W3By for ; Thu, 05 Sep 2024 00:11:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzft96m4mz4D9M for ; Thu, 5 Sep 2024 00:11:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 4850BES6031199; Thu, 5 Sep 2024 03:11:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 4850BES6031199 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 4850BDUh031198; Thu, 5 Sep 2024 03:11:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Sep 2024 03:11:13 +0300 From: Konstantin Belousov To: Jacques Fourie Cc: Cy Schubert , Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space Message-ID: References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-1.46 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.97)[-0.966]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4Wzft96m4mz4D9M On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote: > On Wed, Sep 4, 2024 at 3:41 PM Konstantin Belousov > wrote: > > > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > > > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>, > > Jan > > > Kneppe > > > r writes: > > > > D > > > > > > > > www.dlang.org > > > > > > The problem with D is data structure definitions need to also be > > mirrored > > > (duplicated) in D. For example, when 64-bit inodes were implemented D > > > failed to build and generate any code. The reason for this was > > > ufs/ufs/inode.h now defined 64-bit inodes while the D representation as > > > provided by the D language were still 32-bit. I had opened an issue with > > > upstream regarding this. To this day they still haven't figured out how > > to > > > implement 64-bit inodes on newer FreeBSD systems while maintaining > > 32-bit > > > inode backward compatibility on older FreeBSD systems (as FreeBSD > > > implemented this using ifunc). > > > > Rust is same. It still uses pre-ino64 bindings for both stdlib and libc. > > > > Looking at the Rust libc bindings I see the following: > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8 > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5 > > Seems to have changed to 64 bit for FreeBSD 12 and up? Rust libc seems to make some strange things to follow FreeBSD ABI evolution, which is not done e.g. for glibc. But anyway, the relevant place to look seems to be a comment and decision code at https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/build.rs#L44 By default they seems to use FreeBSD 11 ABI from freebsd11 module still. I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD. From nobody Thu Sep 5 00:19:54 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 4Wzg3r3Fynz5W41y for ; Thu, 05 Sep 2024 00:20:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzg3r16tjz4J6Y for ; Thu, 5 Sep 2024 00:20:08 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-498cd1112c3so38516137.0 for ; Wed, 04 Sep 2024 17:20:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725495607; x=1726100407; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r0dUOtaoVdUp7a4gmvXL7z7bVf5DA8pa5R4zXalNPvE=; b=LyC/bj2nMScItifigkJg9SGrYu3DVaIM55mpb6wMsyhQHPtLaiiWRrkpHSrJwb5u2U BtzZQuCUTb9ClrfQZsV2cT3LO9J7d2m15V/xTv2s7JZ6gGoepMvbzwIrjH/FnP9lwuAb YgNmmi/q5vLo5HZXfARzYmpU7Xm6yyn/26qhClHFKVdgnJFbYBgxxCkWG4F0SCwjFlFl +2kIsNcC/JicpwiLel6MPk+TqHny8UFrdRL4lgrGBsu7BLfdR+FpBf+DGPLWwfVG/6Ns Bes1mm8zfKrdI38pTjGX3J3UBSHBBe51iXdY6QyW74ohaWzIsCFKsNRMH+Bu2teDL8vb GNdQ== X-Forwarded-Encrypted: i=1; AJvYcCU8yFQ63i+GU6nqh/JEkJkvhXejUOJOpI2MasrxD+1pHFKhE5hgz426ov0bbfISgwrb64N49zGBjJuOOgznnbA=@freebsd.org X-Gm-Message-State: AOJu0YyDftjMBm4ec8snZTtjXoKRGuWiTuv9C+vDkfjLWsi6rSo84Yj4 wyfetpuzDknXZb20gfYvoIQpjDr+CRgkNcljKq0xthhlo5YqqE7Bc/Egr2o9UNLkuvNDUdoxLt6 3iBULu36jUW54mQOAHgw5kaXSUnKF5ci2 X-Google-Smtp-Source: AGHT+IEqCaijqyWYxBeI4Rais79ex/9D2k71KX8qWSRFDRrAv9PHJ/BQhH/hUczKATjO2m8yokVUhZlVQATwLO1XDBI= X-Received: by 2002:a67:fa91:0:b0:49b:a93d:3d0 with SMTP id ada2fe7eead31-49ba93d0904mr8133145137.1.1725495606909; Wed, 04 Sep 2024 17:20:06 -0700 (PDT) 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 References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> In-Reply-To: From: Alan Somers Date: Wed, 4 Sep 2024 18:19:54 -0600 Message-ID: Subject: Re: Rust: kernel vs user-space To: Konstantin Belousov Cc: Jacques Fourie , Cy Schubert , Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Wzg3r16tjz4J6Y On Wed, Sep 4, 2024 at 6:12=E2=80=AFPM Konstantin Belousov wrote: > > On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote: > > On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov > > wrote: > > > > > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > > > > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>= , > > > Jan > > > > Kneppe > > > > r writes: > > > > > D > > > > > > > > > > www.dlang.org > > > > > > > > The problem with D is data structure definitions need to also be > > > mirrored > > > > (duplicated) in D. For example, when 64-bit inodes were implemented= D > > > > failed to build and generate any code. The reason for this was > > > > ufs/ufs/inode.h now defined 64-bit inodes while the D representatio= n as > > > > provided by the D language were still 32-bit. I had opened an issue= with > > > > upstream regarding this. To this day they still haven't figured out= how > > > to > > > > implement 64-bit inodes on newer FreeBSD systems while maintaining > > > 32-bit > > > > inode backward compatibility on older FreeBSD systems (as FreeBSD > > > > implemented this using ifunc). > > > > > > Rust is same. It still uses pre-ino64 bindings for both stdlib and l= ibc. > > > > > > > Looking at the Rust libc bindings I see the following: > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c997= 5b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8 > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c997= 5b4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5 > > > > Seems to have changed to 64 bit for FreeBSD 12 and up? > > Rust libc seems to make some strange things to follow FreeBSD ABI > evolution, which is not done e.g. for glibc. But anyway, the relevant pl= ace > to look seems to be a comment and decision code at > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/build.rs#L44 > > By default they seems to use FreeBSD 11 ABI from freebsd11 module still. > I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD. The short answer is that Rust binaries still assume a FreeBSD 11 ABI. The slightly longer answer is that while definitions are in place for FreeBSD 12, 13, and 14, there's actually no way to enable them outside of libc's CI system. CARGO_FEATURE_RUSTC_DEP_OF_STD is a variable set while building the standard library. It allows the standard library to use a different FreeBSD ABI version than libc. And here is the PR that will finally raise the ABI to FreeBSD 12. It's not getting much attention, unfortunately, because none of either libc nor rustc's maintainers are FreeBSD developers, and they're afraid to make changes like this. https://github.com/rust-lang/libc/pull/2406 From nobody Thu Sep 5 01:10:06 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 4Wzh9l4HH2z5WFTw for ; Thu, 05 Sep 2024 01:10:19 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wzh9l1sl3z4R0Q for ; Thu, 5 Sep 2024 01:10:19 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-4fcfd6b870aso108899e0c.0 for ; Wed, 04 Sep 2024 18:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725498617; x=1726103417; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BIZ89h+PuRX2lUc15IHU5NwgTfFNIb+y2I3sAIQtyas=; b=F6kiIayaXitUjFxybkxNCEmfl35rDeDBxz9nejZBkAB6OGFB7wlwO2eUQUc2x/QxrN gHphg1K08GVgD2hiIRK/lrfn0ESWX1Gzx90ZqDwpjqXP6kf4woms6T4NDSESVBDWtv1I fgzQIlbPFgrj3atPm8QGJkGwHhfS3vC6HHze8OfaQwrc91Az4MyTlDENi07EbzPx7JuS B4acTkhBuCya/K4JMnaoYZSYxYoU/Kd67DYWfE7GHbAT86i96euQCrbKc2SziVWYHyR2 GhucDUmY7DJneswhHjcCfd6l/hHso3xL6I+685ziCAvnbPT6icJLV4F2HmGEIPbXIIat T1Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725498617; x=1726103417; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BIZ89h+PuRX2lUc15IHU5NwgTfFNIb+y2I3sAIQtyas=; b=qzOtD1IVL41Qxbkqs26e/HFwafanWTTITVhYQ4JNIWrJ5DkURV8nxKShewKuJDUVds /lRUJ5OczzD4D19A7Rki4TUJaZMWY23exZ/IVwvHoZNk4vT+2YYhpcwbefsL5Xw4iMGS Cn01ndK1ijaCg/c4zD0HFsH8Pzenv6lIIsEj8vk2Itn7dAYtplHB7D0/mYbJGZ9GnqQr +xhlXVAsIMXl/zPjvHdqjtDsxPs/StoTuSUqYf3iG/M2svoeyB2HBK6lSVfuaeRNNipF uzaawLRkFxcW/reAZNW/Drm2CrooM1cbSVZuWQh0Q1OgqWWMfekuYzW1RKIFSU4mUWdH bhvA== X-Forwarded-Encrypted: i=1; AJvYcCUQp19yPZP0UKAW8ZCPdxOUd91TPwBFC5S6Dkewmn6pGNJzQzDdMjkk/G06EwnbNPrrD1pVt/Ud9KVy7sSZ0jo=@freebsd.org X-Gm-Message-State: AOJu0Yw5F5t5vJL7NXUZR8i2KSW1dsKdm+2FmVMytYvTYCKzDgVbZ/lC UcSIElaMbewq5CNl3VVOiBzf4Y+1ssMqY9i0ebdBgNrb6ZY5YLnq/NqHtjRHaFthSuWMLsDIA/K 4+o0NQeJf0e+g12IV42e+vQ1o0Tr6xFyRRYpWfg== X-Google-Smtp-Source: AGHT+IEICHGde84aE2IT/YZx8vKUXkvyKqfRSuvJ6/CahUUUVFs4A7+Pt7Z7mswbAHElJ/68q5uBd47ij3/CJwZu6xM= X-Received: by 2002:a05:6122:d10:b0:4fc:d9ef:3be6 with SMTP id 71dfb90a1353d-500aad16685mr16294061e0c.2.1725498617194; Wed, 04 Sep 2024 18:10:17 -0700 (PDT) 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 References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> In-Reply-To: From: Jacques Fourie Date: Wed, 4 Sep 2024 18:10:06 -0700 Message-ID: Subject: Re: Rust: kernel vs user-space To: Konstantin Belousov Cc: Cy Schubert , Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000243d8b062154f445" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wzh9l1sl3z4R0Q --000000000000243d8b062154f445 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2024 at 5:13=E2=80=AFPM Konstantin Belousov wrote: > On Wed, Sep 04, 2024 at 04:43:31PM -0700, Jacques Fourie wrote: > > On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov > > wrote: > > > > > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote: > > > > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>= , > > > Jan > > > > Kneppe > > > > r writes: > > > > > D > > > > > > > > > > www.dlang.org > > > > > > > > The problem with D is data structure definitions need to also be > > > mirrored > > > > (duplicated) in D. For example, when 64-bit inodes were implemented= D > > > > failed to build and generate any code. The reason for this was > > > > ufs/ufs/inode.h now defined 64-bit inodes while the D representatio= n > as > > > > provided by the D language were still 32-bit. I had opened an issue > with > > > > upstream regarding this. To this day they still haven't figured out > how > > > to > > > > implement 64-bit inodes on newer FreeBSD systems while maintaining > > > 32-bit > > > > inode backward compatibility on older FreeBSD systems (as FreeBSD > > > > implemented this using ifunc). > > > > > > Rust is same. It still uses pre-ino64 bindings for both stdlib and > libc. > > > > > > > Looking at the Rust libc bindings I see the following: > > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs#L8 > > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs#L5 > > > > Seems to have changed to 64 bit for FreeBSD 12 and up? > > Rust libc seems to make some strange things to follow FreeBSD ABI > evolution, which is not done e.g. for glibc. But anyway, the relevant > place > to look seems to be a comment and decision code at > > https://github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b= 4eb132/build.rs#L44 > > By default they seems to use FreeBSD 11 ABI from freebsd11 module still. > I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD. > > CARGO_FEATURE_RUSTC_DEP_OF_STD is an environment variable set by cargo when libc is built with the rustc-dep-of-std feature, as is done when building the std library. What this means is that the std library uses a libc ABI that is backwards compatible with FreeBSD 12. When using a standalone libc from crates.io you will get libc bindings that are backwards compatible with FreeBSD 11. Definitely not entirely clear to me. I made a small sample app that prints the size of libc::ino_t. Building this app without any environment variables defined results in a size of 4. Building with `LIBC_CI=3D1` results in a size of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=3D1`. These tests were done on a host runni= ng FreeBSD 15. --000000000000243d8b062154f445 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 4, 2024 at 5:13=E2=80=AFP= M Konstantin Belousov <kostikbel@= gmail.com> wrote:
On Wed, Sep 04, 2024 a= t 04:43:31PM -0700, Jacques Fourie wrote:
> On Wed, Sep 4, 2024 at 3:41=E2=80=AFPM Konstantin Belousov <kostikbel@gmail.com&g= t;
> wrote:
>
> > On Wed, Sep 04, 2024 at 03:15:22PM -0700, Cy Schubert wrote:
> > > In message <78BC157F-6E30-49C4-931D-9EB5= 39BD0322@digitaldaemon.com>,
> > Jan
> > > Kneppe
> > > r writes:
> > > > D
> > > >
> > > > www.dlang.org
> > >
> > > The problem with D is data structure definitions need to als= o be
> > mirrored
> > > (duplicated) in D. For example, when 64-bit inodes were impl= emented D
> > > failed to build and generate any code. The reason for this w= as
> > > ufs/ufs/inode.h now defined 64-bit inodes while the D repres= entation as
> > > provided by the D language were still 32-bit. I had opened a= n issue with
> > > upstream regarding this. To this day they still haven't = figured out how
> > to
> > > implement 64-bit inodes on newer FreeBSD systems while maint= aining
> > 32-bit
> > > inode backward compatibility on older FreeBSD systems (as Fr= eeBSD
> > > implemented this using ifunc).
> >
> > Rust is same.=C2=A0 It still uses pre-ino64 bindings for both std= lib and libc.
> >
>
> Looking at the Rust libc bindings I see the following:
> https://github.com/rust-lang/libc/blob= /72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/= freebsd11/mod.rs#L8
> https://github.com/rust-lang/libc/blob= /72c40004a3568849055c0bab5c92c9975b4eb132/src/unix/bsd/freebsdlike/freebsd/= freebsd12/mod.rs#L5
>
> Seems to have changed to 64 bit for FreeBSD 12 and up?

Rust libc seems to make some strange things to follow FreeBSD ABI
evolution, which is not done e.g. for glibc.=C2=A0 But anyway, the relevant= place
to look seems to be a comment and decision code at
https://= github.com/rust-lang/libc/blob/72c40004a3568849055c0bab5c92c9975b4eb132/bui= ld.rs#L44

By default they seems to use FreeBSD 11 ABI from freebsd11 module still. I do not know what is CARGO_FEATURE_RUSTC_DEP_OF_STD.

CARGO_FEATURE_RUSTC_DEP_OF_STD is an environment vari= able set by cargo when libc is built with the rustc-dep-of-std=C2=A0feature= , as is done when building the std library. What this means is that the std= library uses a libc ABI that is backwards compatible with FreeBSD 12. When= using a standalone libc from crates.io yo= u will get libc bindings that are backwards compatible with FreeBSD 11. Def= initely not entirely clear to me. I made a small sample app that prints the= size of libc::ino_t. Building this app without any environment variables d= efined results in a size of 4. Building with `LIBC_CI=3D1` results in a siz= e of 8, as does building with `CARGO_FEATURE_RUSTC_DEP_OF_STD=3D1`. These t= ests were done on a host running FreeBSD 15.
--000000000000243d8b062154f445-- From nobody Thu Sep 5 07:23:12 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 4WzrPw1M9Yz5VTWw for ; Thu, 05 Sep 2024 07:21:24 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic313-22.consmr.mail.ir2.yahoo.com (sonic313-22.consmr.mail.ir2.yahoo.com [77.238.179.189]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzrPv3nnKz4Tcw for ; Thu, 5 Sep 2024 07:21:23 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725520880; bh=6q80vt+IAY0NpO3jTYqomF+f9zT8INz+2VWMPxEc9/I=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=pIYy6QQDp4eoYM39rOLdkPzqOCLo08TzRw+MPwfioDkbt9/CZXfKr4rj8uXqnldVLKGZb6zwm8AIy9Rz38/RkdyQPSdd4F7TlgudKIRMNCzXmf6eGvScKyb4Hfq3AQxj1d2h4gLNlvydxfwEjyIH5sSrvsqHZkBzOzgrujRXsosVQKUyTw/bme6nlsgzI+0RoNNWQzTC3nRb6qrq1N7GbAFoqWhU59TYh2on+U49eluBwN1DdtLq0zfKB/vEXldrpfCajnVwxcK73ZuoTLj8JKKQoaM/FW2NNR2g7XrUEWi6nen96xnRq78Rs343suU2Pt+kUyEvc9gJO4VN4YCb+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725520880; bh=K0a/yMPMvLRPojXgo44YPA3L1rWtlraDB+OgtwZNptA=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ku5dDoKND0nvN50aTWzSXcsUnEIryqYD6aumcKIGOzfmYKBIxeH1TGT0Dqm6sMdgfgEwlB292kko/GX4vvZrG2MJ7DojdX4qXsWPKPbrqOfbqlkSkwOOAwNUncoqGZjqIhlgPaebiIMaZF6/HRNH3+hIYbstB5UNBUqQ9paRa1MMIT4E0nvNVPR47h+XPwbdm/Sd6eEciI4fYbebumy5tW4cPiA1HjvuaBijtk82BmRKEJtYzF87g3fYMRNrhmUYhYrzUIwhJVpAL56EELF+J/DVIU39vSzdr0r74mu24gkC+YJ+rey+3EX6UOpTYkN0cTOxzEsm92ef3w9YqSXgfw== X-YMail-OSG: idrBW.EVM1lUmYvqhJkq58dQiddDMHVcZOZ7JNVJdmz6eQBRYWilVSHJ6l9TS8N 2y.HUFynoIlrHFSSYw9MhGpd0pVD33wu.G7OvZTsHOdgGtWLyTK63rgZnrnx4MOV5jGUAV3DEZOR cQ1Fsd.frIycLyMTHmuHVJ8ZsVpJywnc0V8fRuxWhFmmF3Y.Gn9bgZ2ZzOGmdR3mKc1b8MYIDkIK 2fe0IUlW2axfm60O5eaxHlBvMPtXcGa291Ab9E0lPNTnkfMyxOcPeJ11VQ9_CcqghdhSPb.IkXkG rwUR87QHvIyocjCY137ictex9Pjp3KyAoSwRjjvZ0h8lYbU_730R71AYGk9LV6XjuQFZKjj.13lV xpnUHJgdygTGh_62rx40p5dfFVgpw9t4iMCAAcVrQGcC0hnCbVTPdU87N33_qjLB8rjzCmg86PwZ kKHhIc8od.kby_QnatNHvVEzADrccbbclOrfL65_tMT2D.T0ga8bgpXLmC3N2AmZLsZDcvH4CvPH AoBmQ4N9sHyChzyskorYnsRWvLgsseWJCbRIs8QDTOZawjUjRf_ZBt.9D3DmuxqYXoapob4PNJNw eQG7gbZah3s82UJ.EthxVtr3igbnL2obeGyh8gBJGUyxPmpocQrathtP2Ocscd03G2LFe81YLNe_ b4m6xkjY2WtKZkLjOA2XabQdujJFGDoHCaYoVpb1NYQU50l8PBzXSUYVDqYbbaDLCPYPS0uYHXyM vizU_pCwEDaNLQVo28VmI8WOnxSAyDxB5nxW37Pi3BEjWTZXEFwytb9.mqMY4KzXbLS_AAPgh_TQ 0VhRKu4WHHBGpgqIdmF1UP84Fjop_aawgYmonEpUc05m7eHYnK5raqdPsoQ1X_kZQ2YfKvQYg2oR IaYQiOuSF2FVW3_G0jRN3EJ.t4fANf2IWHaZEV4oncrh9ioOZDw7gsI1k5xvhomrQ2JWfcSi_i4n Ihh2nkp4_E060P9APtd7iPNAloOVA4h7.SG_Vh_hQAYhTJyzeG7jSC82ZuHRwzEP.obAM37FMl18 DHf79vT3v49wID8mlrDSzsThsOE2k99e4H4a0JDawaKWXdsoLYzuRnbIcdbADl6zqysxKHv8SM6H ComoCFgM9.FOMpWjOmKHVDLrUbDlpGuR2CqIs7_uZ.oMcBiNf1FJkclzRUFO4onkAyoOL71ikQB7 uszsoIUVunixx8dRJH_7t7VrSfl2iFWp3l6_3.Cf1s4K9lfzmpw28sinNfXGiQenOGTLRIH82IoN dxbG5kFvnY2PiHHGFr.XddhxmLTGjrA0K.KLPlj_1gWsLgLZRsSutlAfaliurf4lZ6NEdziZs.WE vA7dASL1NhAoynZVRDgNd2cZXMj8xAF.kO5QO36gCNWCRWfpPoArv0ayAUmRUcCZwKpgVmbwZngN MfS1zcMJ4uq.S..kRwhZ_OPjBnTEPRLajKWnQ.5us98AV3tQsAVtFJa0zzpLzEoBxb08_1zFlLAj pTDmXAE.GOfuss2ijuaFXXwu0M7fdI3iiEcKwY8.pt_krocTjkxbjAui8S5Yw_pFE2ANTZ2jyakK NmjADps7GlSSJccYTJMoXxnX_Ty_tnTHD4m14KG4T8ybz4dHZCdH2cEWffwf14cygjdzmgMYIaM3 42BZ6bjOsUCiFaMPvXNcXiTzvqYjve5KMomi2vlEI8Xi.KVvhUp.jq.iHvxS25WVEFwYdoVAN3uK btgzbtkF_UIE37NstLkTGIthq10TCX8syND0xSKyTmIrMuJMtaAERr0CuA2B2WOZjjo__b3bxALm dDYrRyVpnCQcfubs58JKkIq7sAb6ubOHnyJmXYHTnMiR9oyD2rts5nxrLoVn1fnZWTiRyKx.KL6V SxS7LMkn8jcJPpkT7LCajxCMWkVj90Wb3DGORh1ya8ptwBw2Awm68dtBq6iATVNxOK1VSTi4O7PZ .ELAO5asc23Ht8kTfe9H2CHyflGW2GxPxbiTcK1qlMWDhzJQnIw_qYdLH3j2V4xpYdjy7qpvlgVH bKnmyUpoRsr_vYPGglz4RAsCGcBckYHCR2Tu2d4Y479eZgKyu8a6.h_sC4rSf4Lxf6j7mZ5BfYlE i4bC716cXnB8poouO96ucew_9jtB7XbVm4QhhZPQt.XM2zexBqslOskUj0U7bCDBurlrFX6XHyuZ EH7l1Pd5HrREjVcit_8q4vxItoDjdKe3157EEXaf.Xoxzv9Wr2c0N5L3Q3j1sdvR_gTN8n4zUJw7 94y2_4RInUk5O8FviC3pR7vaWN1I- X-Sonic-MF: X-Sonic-ID: c859b3cd-9bfc-4a82-9d23-142eea43ef7d Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Thu, 5 Sep 2024 07:21:20 +0000 Received: by hermes--production-ir2-6664f499fc-5vwr7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5ff7d00b86e3a92ed490eeec1979dc42; Thu, 05 Sep 2024 07:21:16 +0000 (UTC) Date: Thu, 5 Sep 2024 10:23:12 +0300 From: Anthony Pankov Message-ID: <605280185.20240905102312@yahoo.com> To: fvalasiad CC: Rob Norris , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) In-Reply-To: References: <202409031131.483BVdax004602@critter.freebsd.dk> <27925916.20240904133623@yahoo.com> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Queue-Id: 4WzrPv3nnKz4Tcw Hello fvalasiad, Yes, I also think that there are young C developers, the problem is how to attract them to develop FreeBSD without money. This mail thread exist in hope to get Rust-developers to FreeBSD while there is a Rust-hype. People are trying to predict is a Rust-hype a longterm or shortterm. The next question is it techincally feasible. The next question will it perish FreeBSD concept in the future. The next question will the binding to Rust lead to deadlock as it was with Python 2.7-sourced projects having not enough strength to rewrite code for Python 3. In my opinion, If I understand things correctly. Wednesday, September 4, 2024, 4:57:34 PM, you wrote: > Being one of the young C developers you are referring to lain, right out of uni from some southern european country, allow me to share my experience. > The introductory class that teaches basic programming is done in C. Basic concepts like if statements, loops, structs, up to malloc(3) and free(3). > The backlog of students for that class is the biggest in the entire university, amounting to 700 people like 2 years ago, mind you the uni takes about 100 students per year. > Additionally, in 3rd and 4th year where students pick fields of study, the one I followed about hardware had barely 6 students in my year. Funnily, we all found a job in the field before we even left uni. > Most students, if not because of inadequacy, seem to not choose C. > I also haven't seem to met anyone entering the Rust cult either, they sure exist but they are also a minority. > While this is alarming, I don't find it impossible for this to come back around if demand rises in parallel with the paycheck offered for the job. Money is a great motivator especially if you are struggling to make ends meet. > Given how the funding situation goes with FOSS projects though, things aren't great as you all know! > Again, that's a completely biased experience cherry picked from a single computer science department in some small country, so take this with a mouthful of salt. > Fotis. > > On Wednesday, September 4th, 2024 at 1:34 PM, Anthony Pankov wrote: >> Hello Rob, >> >> > What I actually want though is high-quality tools to make the kind of >> > problems I need to solve easier for my puny human brain to manage. Rust >> > is an approach to solving some of these kinds of problems. Other >> > approaches exist, have existed, and will exist in the future. >> >> >> I'm interested in your opinion. Do the tools like PROMELA-SPIN used for some (critical) part of a C-sourced project will give more correctness and less error prone compared to rewriting project in Rust? >> Is there an actual possibility to make such a tools integral part of project? >> >> Wednesday, September 4, 2024, 11:03:13 AM, you wrote: >> >> > On 03.09.2024 11:31, Poul-Henning Kamp wrote: >> > >> > > But first and foremost: There has to be a good enough reason. >> >> > This is a near-enough hook for me to hitch a couple of thoughts on to :) >> >> > I work on ZFS, primarily on Linux with slowly increasing amounts on >> > FreeBSD too. By a long way, the kind of work that is the slowest and >> > most complicated is around complex locking sequences across multiple >> > threads. In most of these, getting it wrong leads to some kind of data >> > corruption that is usually impossible to track down. >> >> > The appeal of Rust for me, as for many, is that there are ways to encode >> > those kind of sequencing rules into the type system so that the compiler >> > can tell you where you got it wrong. But, I don't actually want Rust as >> > such. I like it a lot, I've written useful programs in Rust over the >> > last decade, and I'd be perfectly happy to use it in kernel and >> > filesystem development if it was available. >> >> > What I actually want though is high-quality tools to make the kind of >> > problems I need to solve easier for my puny human brain to manage. Rust >> > is an approach to solving some of these kinds of problems. Other >> > approaches exist, have existed, and will exist in the future. >> >> > This is mostly aimed at the "C is totally fine" crowd. I like C, and I'm >> > pretty good at it, but it absolutely not good enough for many kinds of >> > software. Frankly, I find "just get better at C" to be the most >> > infuratingly facile "argument" against Rust. >> >> > (And I would love to get better at C. If substantially better C tools >> > are out there (on whatever axis you like to measure that on), then >> > they're either not visible to me, or they're not usable or >> > well-integrated enough to be in my standard kit). >> >> > There's plenty of plausible reasons not to include Rust in the base >> > system, many of them being discussed on this list, and I'm learning a >> > lot reading along. Just please don't pretend the problems it's trying to >> > solve aren't real. >> >> > Cheers, >> > Rob. >> >> > -- >> > Rob Norris | robn.au | robn@despairlabs.com >> >> > Working on OpenZFS, because there's a lot of data out there and it'd be >> > nice not to lose any of it. >> >> >> >> >> -- >> Best regards, >> Anthony Pankov -- Best regards, Anthony From nobody Thu Sep 5 07:25: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 4WzrVq0MHQz5VVdM for ; Thu, 05 Sep 2024 07:25:39 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4WzrVp6yWbz4Vrg; Thu, 5 Sep 2024 07:25:38 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725521139; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ICfMuyxwhA9hJzJMC46BqH8dW87oTKaK402sN1agJ/o=; b=JqDKCoaaDEbXJNTfC3j3+jVffgrWzd+pWHsFNirbuOh8XIY2Uip8H2u7YX1QCDesrkWG4N 57pqR4KMGO2d24YPdXrXdZuLY9cO4FD0rz/sTdqgVQLisX4EswfOV+oe/koUOkmZH9Ps4Q kxKhtNvjQ1Osa5Ll5KBzFkxReG9eelufQ9BB0xfhwyyP/TJL86J+5cnskzjDKN6LWqYVAP S43YQ/qFMm52UC/WXJOv4ja6BMqo6O90a67TYgFF9JDPrv/Bvja02pv1clMwm2QDsFspY4 bS50B4SpKcoIy76OI03Hfmcw0UhSr1uLsyK6xXsrB8mb7iutpHviRcSFKBDe7Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725521139; a=rsa-sha256; cv=none; b=bCUgj//8FfjwgSejt+n+m9FxLKlYpwwEDc0OSWDUb06ydJzHA3E5uX6tiOVn84aRzTNqeB HFcajf1ScQKxbey8BxptUrSjh8yDIoUe1y9tkaqOZ4sjo7dNQJ/S22R8mIUHivJSTPA6Ti 4T6eXVt2NY5uN6PfU9+QojZWDwTQsdY1zDQdQ+f/3Hq1qN/BFM8bhfhlUbtLwu1YDTYd2P T+EamQj8E2tAsR+LNoKfVDC9jkefopz6DZgSLGeqVBFc18fLz7oTePN3vPsaqr2pUDpSAu QTnpTNls+pcOmmxjapd54d0Qqij1XoXe1uXoDSxJziyyDo3XJjR4tIV3kxKd8Q== 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=1725521139; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ICfMuyxwhA9hJzJMC46BqH8dW87oTKaK402sN1agJ/o=; b=lYV81iQi4OZV0A9TJqkTSgACNvPGhM+q3TVPZvMHs4isWQM+Y72U6GQPu3+8c3pKgARc92 lB0ETksV12sKlCwBfcGZq8EPco866XZOXKeYoBIB78EbxYC0FjuLg3LwigyyiaH5QBoc6z XzOfNVw8YZvZwaz+wQXdbOkq5OKTJ4Tvfwvc2mU7PGn6pienIjjSz/swJBDRMqSzwHlNcW EAj+XC0ZD2BgWvO0mcFT5wr0G2s8XAwfjBl3dj5urnOoQKleB/ch3bl9rRntYcPpu50C8n CkeaX+WBM7lagi9tnLwH3C+sKS53k5Y6vDa/yl8QlXQl2pLLJ2UZHQrvqiuEsg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WzrVp6M8Lz11nT; Thu, 5 Sep 2024 07:25:38 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 254615123; Thu, 05 Sep 2024 08:25:38 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: Rust: kernel vs user-space Date: Thu, 5 Sep 2024 08:25:26 +0100 Message-Id: <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> Cc: Bob Bishop , freebsd-hackers@freebsd.org In-Reply-To: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> To: Stefan Esser X-Mailer: iPad Mail (21G93) On 4 Sep 2024, at 17:42, Stefan Esser wrote: >=20 > The LUA version is much shorter and easier to understand (if you know > LUA) I am far from a Lua expert. I started using it quite recently because the be= st choice for a build system for the RTOS I maintain was written in Lua. I f= ind it overly verbose at times, but, in spite of this, I rarely have problem= s reading other people=E2=80=99s Lua code. It took me about an hour to go from never having written any Lua to writing s= ome Lua code that actually worked (and that we still use). I see that as a h= uge advantage. There=E2=80=99s a lot of C code in the base system that took m= e ages to understand. Some, such as rtld, because it=E2=80=99s intrinsically= complicated (though the fact that the authors are allergic to documentation= doesn=E2=80=99t help: there are subtle phase ordering things there that sho= uld not have been committed without comments explaining what invariants futu= re changes must preserve) but a lot of command-line tools are doing things t= hat are fairly simple but the code is significantly complicated by the fact t= hat C lacks abstractions for them and so implementation detail of data struc= tures is interleaved with algorithms. David= From nobody Thu Sep 5 12:01:15 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 4Wzycv0BqXz5Vspy for ; Thu, 05 Sep 2024 12:01:19 +0000 (UTC) (envelope-from des@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 4Wzyct46BVz4Crh; Thu, 5 Sep 2024 12:01:18 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725537678; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ew2lHE1HSvZmT+6304XESh3oeAul0hsBPE76dKSY9K0=; b=YYQjQ5GiD8uZLKjADoTNS5M8K8UOjjpgVKr7aL4Ha/km95K53MO8YeiWzcdzL+8I4D89zu 22BNtnygIxMoLYVGKkbcJVivtqdJR7CHoHMms3p+nSEB1/cupM86r+GqPACObKoihrzTwP GC0Q+dUr5PnvjploaDKiWS4iMg7SQiZS9RlDBgxO5X8Aj/K4JzcDxtVwYM6hrCOAdodFLQ /zPEL1tFQee3/5cFj9vCl6+W0YsPc74E26z1WjP9H1l3Hz+nvkTlnyxIOlwcMpBMUWEtZ2 C/YMm53JmGfVyXi6ZTzBoHR0U7caGtlcIJTKFzoz38SVzPWVK3IPdEOn6r9PNw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725537678; a=rsa-sha256; cv=none; b=ykw6KRQaxQIj3Rbbho1foFyvVYF6qy8TobcIlhC7Jt37/JRRITW9Wvdi6KmmsklNOK7ax0 uV9fMpsao++kpbO4GTUz9bxF3m925CLmJ5L27VZt8P4q/XgogGF3E9KtdzNq5VuCmsdm6g IqWyeQOT7eXOp5VByBRfS+T+gd0doH4PFEP0Wq0dvFDMCpzRb41PzfmjLKa/m+pV2dfP6K selqeO8dFDG1qiIWk6vf7UDGeF/DRES34YN8/57s15pVwEdQjEv8RK4TdSY8wRGRA4yTET 98pH+YkEBAbu4zUSelvEG4LJaT+XuKpGXbzeocpv+7f5HAIwDAfaR19fEsEnnQ== 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=1725537678; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ew2lHE1HSvZmT+6304XESh3oeAul0hsBPE76dKSY9K0=; b=XolKsxqmcW+/XDbtKDrJWWnBxOw4IaBQvBU0CRb5IPuakEfvLULnyr3YudCjTVemSI9QPr VFSMooBPLreIehqlFQpRlwISsMAqwHgf819GuzSfm7juQN44VyfxRq04qRj2iM9q9uJI0h fchLcjoX36WHAV/HuICnzbsS3GnXKXX6PCywzAXfTc62/+TA7acagKFMKXNNTaCvF777Bd tZbmNlYBZw8BYjmn0m8y9Fc8wQeFOfKUHxgfzJWO11q3GlIjM2Gu8OWTgEcNmJUdegKaQu nA21hl8h8XbiXJAW8Nax4s2r/hvXWSLIKmbFbCEs77RN/1Tb7ftW0FU5dWjvSw== Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:386:9c20:922e:16ff:fef1:acef]) (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: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Wzyct318rz16LK; Thu, 5 Sep 2024 12:01:18 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id D1A4CBECCF; Thu, 05 Sep 2024 14:01:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomek CEDRO Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: (Tomek CEDRO's message of "Wed, 4 Sep 2024 18:00:12 +0200") References: <202409031532.483FW0If007252@critter.freebsd.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 05 Sep 2024 14:01:15 +0200 Message-ID: <86h6au2ttg.fsf@ltc.des.dev> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tomek CEDRO writes: > The difference in design is better seen on a resulting mobile phones - > all iOS (BSD based) devices have the same base that can be extended > with userland applications, while all Android (Linux based) devices > are completely different (base applications, bundled applications, > icons, even keyboard layout, etc). The percentage of BSD-derived code in iOS rounds to 0. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Sep 5 13:15:43 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 4X00Ll5WWcz5W2W9 for ; Thu, 05 Sep 2024 13:19:11 +0000 (UTC) (envelope-from freebsd-hackers@phoe.frmug.org) Received: from frmug.org (enterprise.frmug.org [213.36.253.97]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X00Ll3cldz4Ltj; Thu, 5 Sep 2024 13:19:11 +0000 (UTC) (envelope-from freebsd-hackers@phoe.frmug.org) Authentication-Results: mx1.freebsd.org; none Received: by frmug.org (Postfix, from userid 66) id 6D94312B4AE; Thu, 5 Sep 2024 15:19:03 +0200 (CEST) Received: by memo2.memo.frmug.org (Postfix, from userid 1001) id 9C2B717A09; Thu, 5 Sep 2024 15:15:43 +0200 (CEST) Date: Thu, 5 Sep 2024 15:15:43 +0200 From: Bertrand Petit To: David Chisnall , freebsd-hackers@freebsd.org Subject: Suitability of Lua as a userland-programming language? Message-ID: <20240905131543.GD1354@memo2.memo.frmug.org> References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> 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: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12322, ipnet:213.36.0.0/16, country:FR] X-Rspamd-Queue-Id: 4X00Ll3cldz4Ltj On Thu, Sep 05, 2024 at 08:25:26AM +0100, David Chisnall wrote: > > It took me about an hour to go from never having written any Lua to > writing some Lua code that actually worked (and that we still use). I made the same observation here, I must add that having a funcional programming background helps greatly. The conciseness of the reference manual is lovely even if I think it is badly organised. I regret the "any variable name is assumed to be global unless explicitly declared as a local" concept which preclude users from writing large programs easily. 1-indexed strings is... peculiar by modern times. I see the language libraries as very limited and unsuitable for system programming---I was frustrated to not find map nor reduce. If Lua is to be integrated into base for public consumption we should beforehand write an extensive library of tool functions that would include at least strings and tables manipulations, functional abstractions, a sanctioned object system and a complete set of system interfaces. By extensive I mean Python-scale. That is a large project, do we have sufficient ressources to conduct it from design to documentation? -- %!PS -- Bertrand Petit /D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D /O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/w E D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul h U mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charpath pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findfont 22 scalefont setfont l s P(x)s exch P T O l show showpage From nobody Thu Sep 5 14:13:34 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 4X01YX4scdz5W6rR for ; Thu, 05 Sep 2024 14:13:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X01YX443Lz4VD2; Thu, 5 Sep 2024 14:13:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725545616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QCC6RG4y2lIIcez8eekcJHGbAOa4AKOThnj4XI9IE5w=; b=OpsS0VA0fBiOItCzSYc4OOcaAexjg2Htf8uDnmD8mYPR5+nmZvox4Lqg3mk1cYJSTFjhfL hbybay113HWmz5XpuGOrwu/bb3x+W6ouK9MVwQ48Fzt1XeWN/yHEbWGGJTtI3wbg12bfX1 hpEI3UslkUaD3+tY5b7+noVA15d8scg4i4kuvVgFsRb4UU1rYBtQz9YVFBwBgx0CctAvxy c37z6y78mYn34hmigxpX45Sbe5sJTWYx8Ht7gwiksMwo2ysAprB3VD1M4Cwsgniy1/epSW qUARY1BTznX3wdly3vZtE48x6/iU5tsvlTNMZBTupYsv4sEbH/H5ToVN8AoOgg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725545616; a=rsa-sha256; cv=none; b=hDzKeetMB/lcQvzkOR3diDbxJrur2BG05XlH+WCViOQWRRvzymhIWI9VB9t2SIlMSNqWnv h5yHDNSOJwjPVg85PT9m+N9ypkc48JJnL6fTYNtZFd1vfeXI3hTzh5jCk/En9KgMgJRlfN O7fqOAZZYECZ7mHPdzgRiIgUdBOEMuCovSjmmo5jxkbvv6cBvH/BsS3IGuTikvHvtJz9tL 0i/ybsviHU84Bc507tXjddm4U58961P4mA/TFzWbwHgy0VgHtMvONS8MFkcJf4NA0s8mbA FeU8weCc62eOH/eF0vWo8K5SXGNa4RoBUsc66a+o7cvba2pjkWS/u40h0BWSlQ== 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=1725545616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QCC6RG4y2lIIcez8eekcJHGbAOa4AKOThnj4XI9IE5w=; b=NHttBH8hNmFEV2kU32dI0daAqbLaKJv1L0tdVFwW6mlPUki7TRYcdT7r9fi+X8G73LyZu2 9VCFqoTlOxmP0T12AeRZ/O8P/Jv7kA5qCgZUfBqfVmNurWggQGQLdst5q4upQJlSO/XDMH 2IbUXfun9Xwz6xxvAycUND8j0HM2nZkxK7Ya+PqdqAJCC+gLp+TDn7ME7iJrg5znCPpPpN PhbnVBI5n8rjkZWF3h28aBtRhIYtnJlUU7hCMx+no0yDyc16kg2Rp1nc4P1+dWvGaFl4OL +/T672RLOdMGpzFJMlEbCgCYeK7q+ob6mr6UY06/4F3EVEz6i6N5zOgcyluO6w== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X01YX1VD7z19CX; Thu, 5 Sep 2024 14:13:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Thu, 5 Sep 2024 09:13:34 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: Suitability of Lua as a userland-programming language? To: Bertrand Petit , David Chisnall , freebsd-hackers@freebsd.org References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> <20240905131543.GD1354@memo2.memo.frmug.org> Content-Language: en-US From: Kyle Evans In-Reply-To: <20240905131543.GD1354@memo2.memo.frmug.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/5/24 08:15, Bertrand Petit wrote: > On Thu, Sep 05, 2024 at 08:25:26AM +0100, David Chisnall wrote: >> >> It took me about an hour to go from never having written any Lua to >> writing some Lua code that actually worked (and that we still use). > > I made the same observation here, I must add that having a > funcional programming background helps greatly. The conciseness of the > reference manual is lovely even if I think it is badly organised. > > I regret the "any variable name is assumed to be global unless > explicitly declared as a local" concept which preclude users from > writing large programs easily. 1-indexed strings is... peculiar by > modern times. I see the language libraries as very limited and > unsuitable for system programming---I was frustrated to not find map > nor reduce. If Lua is to be integrated into base for public > consumption we should [...] We will not be exposing flua for general public consumption, but anything in base is welcome to use it and we're happy to expand our collection of modules as needed. Thanks, Kyle Evans From nobody Thu Sep 5 14:18:17 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 4X01gD1J2lz5W7JH for ; Thu, 05 Sep 2024 14:18:32 +0000 (UTC) (envelope-from bdysonsmith@gmail.com) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X01gC4bftz4WSB; Thu, 5 Sep 2024 14:18:31 +0000 (UTC) (envelope-from bdysonsmith@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-2055a3f80a4so6927665ad.2; Thu, 05 Sep 2024 07:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725545910; x=1726150710; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yj1DqTpswq/GzDm9DV9URKXMIzMUeRCvB9cCzLMbDZE=; b=Jy2BScXA7hNZXlWsqJ9EvG5Tfk9JhY2EW2X/SYDHZY+3z+sMY5qtlVfU5w0ycaU0LF dHxWQhNXR+w8FUu/lXr4fkCVRaSiISECrStXsVdBuxZHDbt6mfqUP4zo7OmR/BOTG6fH GoPLffAxGM1KwBDsY6C1t4X0QYvndjsrLvlieQUfj9fn0lfc7BoOetQIMpGdJnK5zVQl 2PsODVyL00M7BRZGhxEcFA5+vVQQVgw3V89KCHQOw8IuFIrRSEI01mmZun8S+or4D1Yg z3uSjxtIsOimC/PeXjvvokGGIlVQWsEphMj3w27yIh3G/i86LOJ73IOiVy9+BShf5MGh aqqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725545910; x=1726150710; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yj1DqTpswq/GzDm9DV9URKXMIzMUeRCvB9cCzLMbDZE=; b=uH/r2ToDjBjOOZH7P36FxrhM2D/p+Jh7uQylXsCKz2kQ0UZBJuApMxNMdi9JiQ+lXR 0b5ekF54FHIqo7stxDedk37S5jCOzeKkxcSijxo9Gh5luHyg/sZoFs/JzlCm/00ODqw+ AvZN2SnBvwo7hITtsCYphAniAD17VqR+2s9v/DTiH9pAhxWagIP3xNZNTBovg+ltLQXy IsB04zYpXuwMvELrwc5m7GKHhHKz9McgBqY67lu370w6bed3WwshcL6uzzUVmuhhIN92 3QXqrrXvAVxRAjr4y+D6Ib2QsFr7CLZp7ewxXpgtEBrj1iVB6ajIOhj9y/bNnerrSevP B1kA== X-Forwarded-Encrypted: i=1; AJvYcCXNf0x23/ID6j0CMBCXyx7gZxQRcchFgtNPMo/lQSYcbyRzaTOZ09qL6zOp0SPPxLOq9ycaE4gMTXBw6gy42lk=@freebsd.org X-Gm-Message-State: AOJu0Yxn87BZBtx6vJqcH+DOz+1RINppJ2ogro7JaUUYrKy75sC9t+2l o7z0Bj3s+a8lyROLHq3iaQeO14sQhdfUtDxVM9jmVIEXNFRxckRKVvFeKOUVe/hnr31IKVIrUZt kKeC5WghB/PL6PrW8uh4aABs86TdbJWWM X-Google-Smtp-Source: AGHT+IFNxuDQ//ALM1+eEnLY8oT6V13kMTwS8o4VC/cX/8Qy2Y7JCqtCpa6eMhnPyxzRBd5gFxAf4l1hJvuPU5gfvzQ= X-Received: by 2002:a17:903:22c8:b0:205:656a:efd6 with SMTP id d9443c01a7336-205656b042bmr182626235ad.53.1725545909665; Thu, 05 Sep 2024 07:18:29 -0700 (PDT) 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 References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> <20240905131543.GD1354@memo2.memo.frmug.org> In-Reply-To: <20240905131543.GD1354@memo2.memo.frmug.org> From: Bridger Dyson-Smith Date: Thu, 5 Sep 2024 14:18:17 +0000 Message-ID: Subject: Re: Suitability of Lua as a userland-programming language? To: Bertrand Petit Cc: David Chisnall , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fd4b8f06215ff6e7" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X01gC4bftz4WSB --000000000000fd4b8f06215ff6e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand On Thu, Sep 5, 2024 at 1:19=E2=80=AFPM Bertrand Petit < freebsd-hackers@phoe.frmug.org> wrote: > On Thu, Sep 05, 2024 at 08:25:26AM +0100, David Chisnall wrote: > > > > It took me about an hour to go from never having written any Lua to > > writing some Lua code that actually worked (and that we still use). > > I made the same observation here, I must add that having a > funcional programming background helps greatly. The conciseness of the > reference manual is lovely even if I think it is badly organised. > > I regret the "any variable name is assumed to be global unless > explicitly declared as a local" concept which preclude users from > writing large programs easily. 1-indexed strings is... peculiar by > modern times. I see the language libraries as very limited and > unsuitable for system programming---I was frustrated to not find map > nor reduce. If Lua is to be integrated into base for public > consumption we should beforehand write an extensive library of tool > functions that would include at least strings and tables > manipulations, functional abstractions, a sanctioned object system and > a complete set of system interfaces. By extensive I mean > Python-scale. That is a large project, do we have sufficient > ressources to conduct it from design to documentation? > > Do you think incorporating a third-party Lua module would be acceptable? E.g. https://github.com/lunarmodules/Penlight I see map, reduce, string manipulation, and more. --=20 > %!PS -- Bertrand Petit > /D{def}def/E{exch}D/G{get}D/I{2 > div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D > /O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 > G/w E > D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mu= l > h U > mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true > charpath > pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica > findfont > 22 scalefont setfont l s P(x)s exch P T O l show showpage > > Best, Bridger --000000000000fd4b8f06215ff6e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bertrand

On Thu, Sep 5, 2024 at 1:= 19=E2=80=AFPM Bertrand Petit <freebsd-hackers@phoe.frmug.org> wrote:
On Thu, Sep 05, 2024 at 08:25:26AM +0= 100, David Chisnall wrote:
>
> It took me about an hour to go from never having written any Lua to > writing some Lua code that actually worked (and that we still use).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I made the same observation here, I must add th= at having a
funcional programming background helps greatly. The conciseness of the
reference manual is lovely even if I think it is badly organised.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I regret the "any variable name is assumed= to be global unless
explicitly declared as a local" concept which preclude users from
writing large programs easily. 1-indexed strings is... peculiar by
modern times. I see the language libraries as very limited and
unsuitable for system programming---I was frustrated to not find map
nor reduce. If Lua is to be integrated into base for public
consumption we should beforehand write an extensive library of tool
functions that would include at least strings and tables
manipulations, functional abstractions, a sanctioned object system and
a complete set of system interfaces. By extensive I mean
Python-scale. That is a large project, do we have sufficient
ressources to conduct it from design to documentation?


Do you think incorporating a third-par= ty Lua module would be acceptable? E.g. https://github.com/lunarmodules/Penlight

I see map, reduce, string manipulation, and more.

<= /div>
--
%!PS -- Bertrand Petit
/D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpat= h}D
/O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/= w E
D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul = h U
mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charp= ath
pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findf= ont
22 scalefont setfont l s P(x)s exch P T O l show showpage

Best,
Bridger
--000000000000fd4b8f06215ff6e7-- From nobody Thu Sep 5 14:30:37 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 4X01xJ2XTfz5W8NL for ; Thu, 05 Sep 2024 14:30:44 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X01xJ1N4Vz4YLf for ; Thu, 5 Sep 2024 14:30:44 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 49946 invoked by uid 89); 5 Sep 2024 14:30:37 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 5 Sep 2024 14:30:37 -0000 Message-ID: <6b8a4e20-4a8b-41b4-a34f-9f0ae32eeced@digitaldaemon.com> Date: Thu, 5 Sep 2024 10:30:37 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: Rust: kernel vs user-space To: David Chisnall , Stefan Esser Cc: Bob Bishop , freebsd-hackers@freebsd.org References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X01xJ1N4Vz4YLf On 9/5/24 03:25, David Chisnall wrote: > On 4 Sep 2024, at 17:42, Stefan Esser wrote: >> The LUA version is much shorter and easier to understand (if you know >> LUA) > It took me about an hour to go from never having written any Lua to writing some Lua code that actually worked (and that we still use). Honestly... With the decades of coding experience I have, it seems that way with most, if not all, other programming languages I learn... I guess such is the benefit of having 'experience'... :-) From nobody Thu Sep 5 16:13:24 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 4X04Dk1Jtfz5WKMj for ; Thu, 05 Sep 2024 16:14:14 +0000 (UTC) (envelope-from freebsd-hackers@phoe.frmug.org) Received: from frmug.org (enterprise.frmug.org [IPv6:2a01:e0d:1:3:58bf:fa61:0:1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X04Dh6bvHz4pdc for ; Thu, 5 Sep 2024 16:14:12 +0000 (UTC) (envelope-from freebsd-hackers@phoe.frmug.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=frmug.org; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@phoe.frmug.org designates 2a01:e0d:1:3:58bf:fa61:0:1 as permitted sender) smtp.mailfrom=freebsd-hackers@phoe.frmug.org Received: by frmug.org (Postfix, from userid 66) id BBA2C12B4B4; Thu, 5 Sep 2024 18:14:03 +0200 (CEST) Received: by memo2.memo.frmug.org (Postfix, from userid 1001) id 240FC17A09; Thu, 5 Sep 2024 18:13:24 +0200 (CEST) Date: Thu, 5 Sep 2024 18:13:24 +0200 From: Bertrand Petit To: freebsd-hackers@freebsd.org Subject: Re: Suitability of Lua as a userland-programming language? Message-ID: <20240905161324.GF1354@memo2.memo.frmug.org> References: <40836902-cb68-45e0-b4ec-623c21aa47ba@FreeBSD.org> <88AC3419-2BD0-4664-80E8-368360E143B4@freebsd.org> <20240905131543.GD1354@memo2.memo.frmug.org> 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: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[frmug.org,none]; R_SPF_ALLOW(-0.20)[+ip6:2a01:e0d:1:3:58bf:fa61:0:1]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4X04Dh6bvHz4pdc On Thu, Sep 05, 2024 at 02:18:17PM +0000, Bridger Dyson-Smith wrote: > > Do you think incorporating a third-party Lua module would be acceptable? > E.g. https://github.com/lunarmodules/Penlight That looks promising, it is modelled after Python batteries, that is a good thing. When evaluating such libraries, after glancing at the range of tackled problems and the interfaces proposed to solve them, because it is a difficult problem, I always focus on date and time handling. It is not rosy, see [1]. Right now I can't pronounce myself for or against the bulk of the library, one must actually use it to forge an opinion, I can only say that the documentation is not par to my expectations--the output of a doxygen-like tool is never good enough IMHO. The only Lua code I have is running in kernel as a set of ZFS channel programs, an environment where one can't import libraries, this make testing Penlight difficult for me. Testing must await for a medium size project not requiring network access which I should write in Lua instead of Python. [1] https://github.com/lunarmodules/Penlight/issues/285 -- %!PS -- Bertrand Petit /D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D /O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/w E D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul h U mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charpath pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findfont 22 scalefont setfont l s P(x)s exch P T O l show showpage From nobody Thu Sep 5 16:21:15 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 4X04P229x8z5WKh8; Thu, 05 Sep 2024 16:21:26 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mail.nepustil.net (mail.nepustil.net [IPv6:2001:14f8:1:1::8]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X04P14R0Jz4r5s; Thu, 5 Sep 2024 16:21:25 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE designates 2001:14f8:1:1::8 as permitted sender) smtp.mailfrom=Axel.Rau@Chaos1.DE Received: from [2001:14f8:21c:10::124] (port=62962 helo=axels-imac.in.chaos1.de) by mail.nepustil.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98 (FreeBSD)) (envelope-from ) id 1smFD2-00000000Kz8-2Y8n; Thu, 05 Sep 2024 18:21:13 +0200 From: Axel Rau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DBFF364F-EFA2-43DB-8F92-72ABA02F382F" 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 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: USBasp no longer works with FreeBSD 14.1 / avrdude 7.3 Date: Thu, 5 Sep 2024 18:21:15 +0200 In-Reply-To: <65c16902-d8d5-4a79-ae77-e097da2eb9d6@app.fastmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org To: Tom Jones References: <30B9438F-FC5F-43CA-9A81-5E75F01017F0@Chaos1.DE> <65c16902-d8d5-4a79-ae77-e097da2eb9d6@app.fastmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; URI_COUNT_ODD(1.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-hardware@freebsd.org]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[chaos1.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4X04P14R0Jz4r5s --Apple-Mail=_DBFF364F-EFA2-43DB-8F92-72ABA02F382F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 29.08.2024 um 09:10 schrieb Tom Jones : >=20 > Can you create a bug to track this and assign it to me (thj@) ?=20 Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281297#add_comment = Reporter does not allow me to set Assignee. Axel --- PGP-Key: CDE74120 =E2=98=80 mobile: +49 160 7568212 computing @ chaos claudius --Apple-Mail=_DBFF364F-EFA2-43DB-8F92-72ABA02F382F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Am 29.08.2024 um 09:10 schrieb Tom Jones <thj@freebsd.org>:

Can you = create a bug to track this and assign it to me (thj@) ? 

Done:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281297#add_= comment
Reporter does not allow me to set = Assignee.

Axel
---
PGP-Key: CDE74120 =  =E2=98=80 mobile: +49 160 7568212
computing @ = chaos claudius

= --Apple-Mail=_DBFF364F-EFA2-43DB-8F92-72ABA02F382F-- From nobody Thu Sep 5 17:06:47 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 4X05PW6BLCz5WQNf for ; Thu, 05 Sep 2024 17:06:55 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X05PW2j7hz44qM for ; Thu, 5 Sep 2024 17:06:55 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725556012; x=1725815212; bh=Alba2T8Wz2fRV07RS8KtRbf6acXdQuBWT3oP6+f+M9I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=I/cfyEqTTqIYGs4oPQgiaP0DkT25HCGkOZCcZPNNqF3zuiTv0EPncqb/fmr8z1naF jer1xeMcAbxd6ENCHTeqFoyint4vwXPOLMh9k0Xx2P7TKZQLV/58BhYOlIqUj3O0lz XulmWyFyMgmMtKC2r7VD0xSl+YhN+5fspyVJ04sTUH9p3QWNOe9E/Uwdc4C2A9LvKi CxTH3VVlKN8rZyUJQmH+XE528tBzI8oVs7zHBIjMvi8pUI/R3146xwdaIbxfjdofrT 5EaxIXm+MewLxy55RdXERUzoOXI6YxOiMyjn590b/i/qpTug7NKeVd+jU/6zQlgfn2 rRf7/QD0/q7TA== Date: Thu, 05 Sep 2024 17:06:47 +0000 To: Anthony Pankov From: fvalasiad Cc: Rob Norris , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: In-Reply-To: <605280185.20240905102312@yahoo.com> References: <202409031131.483BVdax004602@critter.freebsd.dk> <27925916.20240904133623@yahoo.com> <605280185.20240905102312@yahoo.com> Feedback-ID: 78761413:user:proton X-Pm-Message-ID: f91700eedb0af484d051a0f6d7223ec6ba825e74 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4X05PW2j7hz44qM Hi Anthony On Thursday, September 5th, 2024 at 10:21 AM, Anthony Pankov wrote: > Yes, I also think that there are young C developers, the problem is how t= o attract them to develop FreeBSD without money. Relying on a minority's volunteering effort isn't the best plan if you ask = me. I am a regular FOSS contributor at this point, but the amount I contribute = during this time working in a proprietary environment is minimal compared t= o how much I contributed when I was paid to do FOSS two years ago. The time= simply doesn't add up. And that "minimal" volunteering effort has not been targeting FreeBSD so fa= r either. Linux steals plenty of the spotlight, while also currently strugg= les with an anticipated C developer shortage, leading them to invest to Rus= t in hopes to attract new contributors. I got to join this mailing list because I met Deb and other members back in= FOSDEM 2023, drawing my interest to target FreeBSD as the first port of th= e tool I developed at the time. Funding issue in FOSS as a problem isn't new, and we can only hope it's goi= ng to get resolved, eventually. Fotis. From nobody Thu Sep 5 18:09:18 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 4X06nn0TPQz5WWdk for ; Thu, 05 Sep 2024 18:09:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X06nl73qPz4G78 for ; Thu, 5 Sep 2024 18:09:31 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-3df0a54623dso660149b6e.0 for ; Thu, 05 Sep 2024 11:09:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725559770; x=1726164570; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A6Z4llo/SZX531S5EHas7PUD5EsxrlO0evBfWqzX0bM=; b=Fb5bH+Ic/pIQhRb/VxLFuoHi04o03f59IoGMPKY6UpeX3vAVP3akVquQ0L4swWUnZY tL60IIB0/UxKw7N898P/OaN7floEwdUqNa4HxDoBkygVjbKOHBHOessgeAXgedc27Gtx AuGxLScYJk/vORo984ESi61I6KUTHLFCFJdyfUmjnYQE7YuABa9F1ubgxGeVkcrj6L2p kemu6emITlFPNTn41bHPtUNz6vDXzA2lnmyg6J3K8E1iutaVhkhcg3BXTMgxTyFD1Wco lhGKamt8uRNp2dBweFyR0DEKbnbn+iI4vdzv4BGuPEqlqp7jvgCfZ+RgpFqlnrnsoTZr aIRQ== X-Gm-Message-State: AOJu0YzqHbxbe7TugO/IuyFPLSs0/U/kz7gF9GTOEqxDkyb5JNPq1Dr7 bbM1xLPM1YLhQgOYLHMp7gLHmDk4YgO3da5C+rSg1KxO1oIqQAw9hsWuUqo+2FN07Oe1EgV+l1m +YhTalV1EC0Ql4AHlw4Z3394Qz2SYGHZ3 X-Google-Smtp-Source: AGHT+IFDHk3N7FFG56Y6X5Edvpt7EQg6tU14hG9xIeqAqVgRy/PkNVGjpsMqNA/Vra6AYidZFu1GTRbGujFFopCu3UA= X-Received: by 2002:a05:6808:1590:b0:3d9:e1d1:157e with SMTP id 5614622812f47-3e029f20b5fmr159199b6e.35.1725559770021; Thu, 05 Sep 2024 11:09:30 -0700 (PDT) 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 From: Alan Somers Date: Thu, 5 Sep 2024 12:09:18 -0600 Message-ID: Subject: The Case for Rust (in any system) To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.06 / 15.00]; NEURAL_HAM_LONG(-0.92)[-0.915]; NEURAL_HAM_MEDIUM(-0.32)[-0.320]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; NEURAL_SPAM_SHORT(0.08)[0.081]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.177:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.177:from] X-Rspamd-Queue-Id: 4X06nl73qPz4G78 By now I expect that most of you have seen the long list of new security advisories that just came out. Strikingly, all were the result of memory handling errors. And none of them wouldn't have happened if their respective programs had been written in a memory-safe language. In fact, of all the C bug fixes that I've been involved with (as either author or reviewer) since May, about three quarters could've been avoided just by using a better language. The real takeaway here is that C is no longer sufficient for writing high quality code in the 2020s. Everyone needs to adapt their tools. Programmers who don't will increasingly come to resemble experimental archaeologists, i.e. people who learn flintknapping to "keep the knowledge alive". Such people are valuable, but definitely niche. I for one don't want my career to go in that trajectory. To summarize, here's the list of this week's security advisories, and also some other recent C bug fixes of my own involvement: Buffer overflow =============== https://cgit.freebsd.org/src/commit/?id=3aaaca1b51ad844ef9e9b3d945217ab3dd189bae CVE-2024-45288 FreeBSD-SA-24:09.libnv https://cgit.freebsd.org/src/commit/?id=a06fc21e770a482c8915411ebc98c870e42dd29b CVE-2024-41928 FreeBSD-SA-24:10.bhyve https://cgit.freebsd.org/src/commit/?id=af438acbfde3d25dbdc82b2b3d72380f0191e9d9 CVE-2024-42416 FreeBSD-SA-24:11.ctl https://cgit.freebsd.org/src/commit/?id=db87c98168b1605f067d283fa36a710369c3849d FreeBSD-SA-24:11.ctl https://cgit.freebsd.org/src/commit/?id=5c9308a4130858598c76f3ae6e3e3dfb41ccfe68 CVE-2024-32668 FreeBSD-SA-24:12.bhyve Integer overflow ================ https://cgit.freebsd.org/src/commit/?id=36fa90dbde0060aacb5677d0b113ee168e839071 CVE-2024-45287 FreeBSD-SA-24:09.libnv https://cgit.freebsd.org/src/commit/?id=c3e6dfe55c0e81d0717b0458bc95128384c3ebe8 FreeBSD-SA-24:14.umtx Use after free ============== https://cgit.freebsd.org/src/commit/?id=670b582db6cb827a8760df942ed8af0020a0b4d0 CVE-2024-45063 FreeBSD-SA-24:11.ctl https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 CVE-2024-43102 FreeBSD-SA-24:14.umtx Uninitialized memory access =========================== https://cgit.freebsd.org/src/commit/?id=ea44766b78d639d3a89afd5302ec6feffaade813 CVE-2024-8178 FreeBSD-SA-24:11.ctl https://cgit.freebsd.org/src/commit/?id=0f2b2276abc305905e7d88619a7abca26b0dd7eb Memory Leaks ============ https://cgit.freebsd.org/src/commit/?id=2909ddd17cb4d750852dc04128e584f93f8c5058 Incorrect union member access ============================= https://cgit.freebsd.org/src/commit/?id=9a5a7c90d5e5971fe2b9c9265e9279a6f173a8f3 CVE-2024-6119 FreeBSD-SA-24:13.openssl Concurrent unsychronized memory access ====================================== https://cgit.freebsd.org/src/commit/?id=1f5bf91a85e93afa17bc9c03fe7fade0852da046 RAII ==== https://cgit.freebsd.org/src/commit/?id=4b3141f5d5373989598f9447ab5a9f87e2d1c9fb Unchecked errors [^1] ====================== https://cgit.freebsd.org/src/commit/?id=35f4984343229545881a324a00cdbb3980d675ce https://cgit.freebsd.org/src/commit/?id=eced2e2f1e56b54753702da52a88fccbe73b3dcb https://cgit.freebsd.org/src/commit/?id=f625d038d2ae59fa1ae81b76079da464ed6db61a Not preventable by a safer programming language =============================================== https://cgit.freebsd.org/src/commit/?id=7d6932d20aedbbb220cd78e90ab4e82d1abaad31 https://cgit.freebsd.org/src/commit/?id=6efba04df3f8c77b9b12f1df3e5124a7249b82fc https://cgit.freebsd.org/src/commit/?id=4b72bab96e8978eaed30fd44f7f51e1b4918d4db https://cgit.freebsd.org/src/commit/?id=b64afa41d56e98b5817aaf14c7deb0fa7e2142fb [^1]: while not memory-safety bugs, Rust's lints actually make ignoring errors like this pretty difficult. So I consider these bugs to have been preventable. From nobody Thu Sep 5 18:20:22 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 4X072b0jHkz5WY8W for ; Thu, 05 Sep 2024 18:20:39 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X072Z585Wz4HlN for ; Thu, 5 Sep 2024 18:20:38 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-6b8f13f28fbso10209357b3.1 for ; Thu, 05 Sep 2024 11:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725560437; x=1726165237; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c6PUQxBXYrgMD4ZfT4fkRIfF9PcSeVZGPjvqi3JVvzk=; b=TtU5Uq+zO6fmVxexxzH6rkGYK8RbRen6OTonWHlp1YJ53c89kIT4aqVVWrFkkQEPDj pFCVl9/vdgqSZJE6jwvLyBc7ecU6BCXWooXbIECSNhM9huaensuGfxFfP3smMAdSW0R3 n67ESIyOOS59jgzkhpts2gTGLh9C5VIIJE5fBV4OZb/CZ8/H0/iHzsw/J6pRoeLpKgtn HVxg6zn5bU5ExvMXsSFQk/iIxT9FQTWHz+Q1c9MYHTVai+EL2DWf7CxsJihPN5Q9AWcl LYgPneYXR1pUzeZ740vtRw5LMtvgmQaRMtI50SxW/g74MEPHtOBe+Hxf6tyZstpJn4RH fVhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725560437; x=1726165237; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c6PUQxBXYrgMD4ZfT4fkRIfF9PcSeVZGPjvqi3JVvzk=; b=sMr9fM0zkS7oycuw59iAB7BDaTl7/U/YJOODHt+YSfaiuIvrIz8ZBF13YdmBaf2b5d 7IQNnYuhJ1NzNUtG/q+VWwK0fTQ4e3HFgrfVbNFL/X0uE3/C/wcMbHnWZFtMSY0FLiiW P6dCxd42wUiCQf6dMApC2me8eAFxzqb9gNWtxwx6IjCtOT69ougp9BpxG5oIBCuK1vKx IBswJIcjX1EkFmnnIGtyFmiNNdkiM0dfJubP039zoHn6n2QHFjcd6axwfY6D44DJ4+fB VecC1K2PJ1/gFtvaUC2voEH7dlW0EDqSR/s1M7YBWUG2+f3kgVlKKgLv+ibLcuq6kT5Z dA4g== X-Forwarded-Encrypted: i=1; AJvYcCWjguPL1RAQxMnYYGM5IIAJmkZcqPRTl/DX6bvQDmfAt4FeshC14wCdsK5CkrBRA9Znnt2lNJ90IFmlNDxLgtY=@freebsd.org X-Gm-Message-State: AOJu0YzHBMxWZxcFgmKMx1dt5X5gdBX8WjdP0rz/OKtYRRMPbM1xGwuV 13WibzgjojCNMmAi9UfxWW1B6PAD7BIIBL4tPa1fCz2LT87GrZ91s+BPKpyZFyU2/5XYMPqb8ZQ = X-Google-Smtp-Source: AGHT+IGezfrAZmZ37OC0QiFR+t24MzBD3iT6LEU0QJqat9qGDmOcCEUJcnpJxjLRBWc2agD+SPGK0A== X-Received: by 2002:a05:690c:6288:b0:6d4:f41d:de2f with SMTP id 00721157ae682-6db45163f51mr8247b3.39.1725560437330; Thu, 05 Sep 2024 11:20:37 -0700 (PDT) Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com. [209.85.128.182]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6d6d99b0b1csm17963027b3.109.2024.09.05.11.20.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Sep 2024 11:20:36 -0700 (PDT) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-6c49c9018ebso11063097b3.3 for ; Thu, 05 Sep 2024 11:20:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWtwllNK0QfSBzYrFWMLt5i8cg7viccVoCsMAEIDO78zYiRCT+wbSALlnM3VjH6oI1imHBsJSuBNJVT1SxlXx8=@freebsd.org X-Received: by 2002:a05:690c:f06:b0:6ad:75f6:679f with SMTP id 00721157ae682-6db44d69beamr440767b3.6.1725560435938; Thu, 05 Sep 2024 11:20:35 -0700 (PDT) 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 References: <202409031131.483BVdax004602@critter.freebsd.dk> <27925916.20240904133623@yahoo.com> <605280185.20240905102312@yahoo.com> In-Reply-To: <605280185.20240905102312@yahoo.com> From: Tomek CEDRO Date: Thu, 5 Sep 2024 20:20:22 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: The Case for Rust (in the base system) To: Anthony Pankov Cc: fvalasiad , Rob Norris , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000d2ac670621635883" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X072Z585Wz4HlN --000000000000d2ac670621635883 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 5, 2024, 09:21 Anthony Pankov wrote: > Yes, I also think that there are young C developers, the problem is how > to attract them to develop FreeBSD without money. bingo :-) not only to attract, but to let them focus, pay the bills, and grow along with the project :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --000000000000d2ac670621635883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 5, 2024, 09:21 Anthony Pank= ov <anthony.pankov@yahoo.com= > wrote:
Yes, I also think that there are young C developers,=C2=A0 the problem is h= ow to attract them to develop FreeBSD without money.

bingo :-) not only to attract, bu= t to let them focus, pay the bills, and grow along with the project :-)

--
--000000000000d2ac670621635883-- From nobody Thu Sep 5 18:34:56 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 4X07MN2zrWz5TbmX for ; Thu, 05 Sep 2024 18:35:12 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X07MN07cDz4MQg for ; Thu, 5 Sep 2024 18:35:12 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-699ac6dbf24so10520107b3.3 for ; Thu, 05 Sep 2024 11:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725561311; x=1726166111; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r1umI405Swgmy3t2SmGMLBszs1/H0OVR/uq6ljcLWXw=; b=VFPO4MIUpLjCrTv064dVE1qbQG6yX2K/lP7kLI8AuzdPFHhQQmz6GIIUorl0Cd7ges Q7wWUwDAaywnOqcqmemtf26pxg0SYTjZHvoRjeHIWMADilxkZxT7WSX9DlbjpKBlTmyF nuOD/stH8qAiWv/HzZ9mtm5cUPKOXO9DIUIsyEPAQoq3+qU+EbjpkeB/cnCswW5H3Lbv VR4g4gxideAZkyJ133VuQRi/ofu45u2JiE3MxQM8ijTvtNyQYpp6bFfn5W4vqT6X3JXP Dg019sYcB2Rz4p5nk07evbZyDL9TyEBEpdrHWEl1IMxO6L1/7J+sIih/ezW14LhC5LcO 3tow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725561311; x=1726166111; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r1umI405Swgmy3t2SmGMLBszs1/H0OVR/uq6ljcLWXw=; b=CImGa3UJxfEj8cd4MGmtgHHMnIVJ+PILEczOCkElucuvvWuZSBtswOi3SynIYtoXEt +X2tgTrf0bszW4OKKrP8L9D7LV2q42x0zPCvn6Snrsg24xzq7jeCg6CBG7k8vaxBwmt6 Otq5FdyLc5M47ZNwHZTo8UoXw6JJ8Yps82Yv5TmkeiLByI5yLOiIwIH6Tr/b+jT1q5zc ExbCUBGHGFu8eAdkhRr0Xtd0sMPS5i8iGArCNFeBdsdnQNDyFOtfYDPv1Cg+g+z2pWcB WIEodxiLpyC6fYf8q0UNjUp4d6TJEng7AQoiIUVKbREVhQgwaXHYtqoEgPkLPFO9QVmN tRmA== X-Gm-Message-State: AOJu0YwcBFKH0YMXoiSu52Y9sdk8MfyAVqulFi7ewZs5qdeB2w+FbLj3 af5kB0QD0OU9Sc3/zn8ofeli7DmL4pREgGnB64WiQd8cVihCqW/S9qGew6av89XXw2i2XikQt7M = X-Google-Smtp-Source: AGHT+IHB5Ih3pl+TEjim42b9yQrMyoJ1dEVPVgDZv6u9gL4/q0GF+N/U+ExQFHUMnr/X5Nosmsdmsg== X-Received: by 2002:a05:690c:438e:b0:672:e49d:430e with SMTP id 00721157ae682-6db44dc5400mr657447b3.15.1725561310924; Thu, 05 Sep 2024 11:35:10 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6d2d4485613sm30386927b3.70.2024.09.05.11.35.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Sep 2024 11:35:10 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-e164caa76e4so1290782276.1; Thu, 05 Sep 2024 11:35:10 -0700 (PDT) X-Received: by 2002:a05:690c:6c81:b0:6d5:6719:4d80 with SMTP id 00721157ae682-6db451549bcmr564567b3.31.1725561309440; Thu, 05 Sep 2024 11:35:09 -0700 (PDT) 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 References: In-Reply-To: From: Tomek CEDRO Date: Thu, 5 Sep 2024 20:34:56 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: The Case for Rust (in any system) To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e342440621638c77" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X07MN07cDz4MQg --000000000000e342440621638c77 Content-Type: text/plain; charset="UTF-8" wow! this is undeniable argument even for someone who opposes the idea (like me) :-) maybe this is time to simply crate a new Open-Source OS from scratch written in Rust? manual rewrite of existing code seems too complex from a technical standpoint. sometimes it's just easier to start from scratch? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --000000000000e342440621638c77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
wow! this is undeniable argument even for someone wh= o opposes the idea (like me) :-)

maybe this is time to simply crate a new Open-Source OS from scra= tch written in Rust?

man= ual rewrite of existing code seems too complex from a technical standpoint.= sometimes it's just easier to start from scratch?

=
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--000000000000e342440621638c77-- From nobody Thu Sep 5 19:20: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 4X08Ml1S76z5ThHQ for ; Thu, 05 Sep 2024 19:20:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X08Mk35p6z4TTd for ; Thu, 5 Sep 2024 19:20:34 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (syn-071-015-252-132.res.spectrum.com [71.15.252.132]) by colo1.denninger.net (Postfix) with ESMTP id E6F3C2110F1 for ; Thu, 05 Sep 2024 15:20:44 -0400 (EDT) Received: from [192.168.10.28] (D18.Denninger.Net [192.168.10.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 9451B3894DE for ; Thu, 05 Sep 2024 15:20:27 -0400 (EDT) Message-ID: Date: Thu, 5 Sep 2024 15:20:26 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Karl Denninger Autocrypt: addr=karl@denninger.net; keydata= xsFNBF1Rd+gBEACmLAH7SAzdQq57ZN56QQEy0jDFfH5BvGOMZgCaP+Y5lJQ5u9WphCoCALMs Rg0o1Q9DRNWgUmy/cgsxioXAEzZFXXzOHPJhwplVOgfjxnoByD5KQhWG8Owm9QmATdtiZPSV 4UYVNUIbZv7btSnnAXysG2OUHajYS5PVeFQxFbhNFq/SS8VaXr1WEVTFa8NFKp2W3/KY1A+U KKDUlYwnOauK3fnY9chF2IRSoxAbBJFrJ4lPGz04HtzNos4Q9CBfTphKcdFjcPntNS9wrqs3 sm+7hLNTH9B2Kj6aekG5UhD03eyP+gevTgBy51RL6ULzI13Kc4aeyOByuBXrA8D2m2Ee67iy 4+ZSxM9Wn1gQce5624OWzCYIGBH2r75Bshp1KHKu36N2rN//kyKYnwl/z6UZB/S9cMUFKZgL gFx7QxpFX/HvSiBcPfcGS0meModpg6qma7/2jRoQAXacslpiT+uOfRGspNbnglkbw435RzX/ kMUclJQNZBBBUpPiGjVCjeBTiAfN8TyjS+pWzwxNCUZWbYO5xVaS0gbIhgVNoBOGn1rdTsdA PP65SRjaoL5KY6bzkkzrXLB2Djx8/p4vr0qIqxIQWbewJq3xKyKGiqI46ae77BF7k0B++Ndx g9K9UeWKl/iJ0eoI0ftR+xH3aIHTU1Or3j/tj4j8Z0tnVSyt1wARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfwQTAQgAKQUCZj4NhwIbIwUJDK6K2AcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG8twBXrj1l42DQP/A0AGcBuGhHzGh2aFyW94B29 ECEkmkxigmQt++AG9xr3Qv4gC6UtSGzKo50SWAdek5peBRTbeDALa/tQvBsbi2aJgYWxZVOV N2XLe89ZjvJuTZqXaG/iaV50es56/cWBlG7VR+5/ijw3uSWO6gZ+L5bkKnQ/p8OWUP0GbtV1 rmEL4DOf6Sel7vOHGLIOgppMxH3DqAgHINZPhOBn/ySnFYNRUyUzp+DxKweH3/6UT8kLST4z UykLcb6HCXEkPM8ECyXkQacE6AfSsrj+tpDv97ZU9UzfprMGY8MmtpACc2509YhdDgljoaGq dfC2//HDKjEt31apoiKwQ9x2oqDBRtkRJoSuqC+rxRDGYMFdxRUBTEJ/j/P3EJdqCO128Jb+ 2iw+0ERUqMyPJWpRXb+J/zdo4ge5RP39LreyNhblEF3aKIvNMj+KrGwznB0Muny8uP73O/bw w7Nkj6HuXbq9gZ1jV6WqHzP9seadWpxLhcR8UQZqgFbO7Q4Y1Lj7TWt/cEoGXe5TeBGO8/b/ Q0g+LF0+/waARlk9dwVx5vBol4ZJ4gDEwzZD6IqDYB5Knenv/wWAdK7WrzLqP4zBzU5vwpJ+ Aj8i+lkqGcaCdtMdRZpa3qR68eKgutuVCzCt3Ydt2Oeiz/D0ccI++FzJgqfD+r4B1pjWT/V3 SRerR30au23XzsFNBF1Rd+gBEADNVFS8nQ+kpKOpgtP+f3bCVxHAm7eHMbX6oew5yZiQwfD+ 1RWNWLVOMeTt7G2e5HsHpJOUwFUJhbDb0omB0r38xTSVSAig9kmUfb7tTMJG2bG7WfWykBOM WIZ4OhCf+ISv9dUkjNgx4ionWotFxwDiPRwWumVQ7WYZmRZlhDWMiaHgKvBrjJ7Y6GKPRbQc 5/0Qz9xGhXKlFxDQrrSMkyRThIOxXqdfD9z3rEsV3ZwOojzNsnkIImnQMKyIAR0FBQop34G9 wDQi7fxk8wGIfDszwfR4oAdDdPGq4gcAvE7Fd3xKyNpGyjSED5szoaFjldaZSXQIffquSUvy sFCTTLRIso5Dn9uQgi57gIv+5mnyKBfm2Z2P6pEQPSt073TED9rS0+JpniJL7rKRVpO5niqw sQJS6ht+JF88rXro+SiwxD/KeDpTuuJ10+ohLVi1Y+X82X7BIQEhqtFp9FVJSds4o/eNyaHd SoqfoeWMy3EV+rdJ3DneXcPS1BgxO57Rko5Hx3NUSVK83ovFb+Ofes9SLNdqNu3xAUcfpRdS DyxzpVbCq6Y2CIojiaweiYe5BOBhmR9OPGhqP8YD7GukYmQufAVuOrIVyctBlVPHgMBb+UX+ ItYXuX4weSJWLOsmM45xd/EYvBq2DWFpKlyihoktNzTGqxGsNeG7gCOEUTAnUwARAQABwsFl BBgBCAAPBQJmPg2HAhsMBQkMrorYAAoJEG8twBXrj1l4s28P/icoshBPgHA86zWSiBYWtR4M TXbg86Yo5tMm64gO2ipXHlDnS0fQOjkJvfo+1e8soq0Rf4RxvKGEDLF9sxLD3z0ptF4Lj8aN zddLPlWFUZ9iOGbDGZhdvnB6YfCWEOXnkXJHfdheYOd/cni54Y4MT1sPMUiPGDlB4Fpu1voL wMZdGfplQYuV+zYv2ezd6Aoc/YwmhixX3YSjy6vFa+7x8OXrGUK69XaZ649GGHpeZzYuLTPw jAfCjbYBk9a24GtQlO/sk9SHRlxIU1e/AflNMtOMYDwuEDLuPgTLe4pRt4lnSdnQSVsFoYz1 nO7XBtyJdUa2rrhcLfhmSxlbJF/4cmNB4ebyT+5v+9ChpMVqzpKBCjyxPm4s+WVq4aYQ7D24 caCcUknD82iMFDFvbV0dm/xAQKZ3k+L/apMhHtUS23dzhJemxWdeQ6Cs2l0FYoGtrEzfUguR Hj7U3opGU6F4dnH1nQt4CbaXAOXM2Zh4ik+z5xRv9ro7fZUG8KSaz8dHKc2scpnJsqdS5XEk NwcHQUCCwSOEPzbugPJY1vjkjlTGWu6ihN7mjxxfthNPGU21/Vfv0d+mlBNdTkl2YOlQtKci YBqkhRb5Re9KC+6O7dWFf5qPZQiD3iUOxUOWsaQhj/CxO+EYk7kxEJxV4tMZfesE90LgTINX Z7FdWd0DYG+m In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------tz2ZXe8FX0LLJVhK5fWywHIE" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.51 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.895]; NEURAL_SPAM_MEDIUM(0.73)[0.726]; NEURAL_HAM_LONG(-0.55)[-0.548]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4X08Mk35p6z4TTd This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tz2ZXe8FX0LLJVhK5fWywHIE Content-Type: multipart/mixed; boundary="------------3YLnouGggY5YYOvYFDxUunlA"; protected-headers="v1" From: Karl Denninger To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: The Case for Rust (in any system) References: In-Reply-To: --------------3YLnouGggY5YYOvYFDxUunlA Content-Type: multipart/alternative; boundary="------------E8Lf4W0eusc3A0g0SXJ0lQg0" --------------E8Lf4W0eusc3A0g0SXJ0lQg0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS81LzIwMjQgMTQ6MDksIEFsYW4gU29tZXJzIHdyb3RlOg0KPiBCeSBub3cgSSBleHBl Y3QgdGhhdCBtb3N0IG9mIHlvdSBoYXZlIHNlZW4gdGhlIGxvbmcgbGlzdCBvZiBuZXcNCj4g c2VjdXJpdHkgYWR2aXNvcmllcyB0aGF0IGp1c3QgY2FtZSBvdXQuICBTdHJpa2luZ2x5LCBh bGwgd2VyZSB0aGUNCj4gcmVzdWx0IG9mIG1lbW9yeSBoYW5kbGluZyBlcnJvcnMuICBBbmQg bm9uZSBvZiB0aGVtIHdvdWxkbid0IGhhdmUNCj4gaGFwcGVuZWQgaWYgdGhlaXIgcmVzcGVj dGl2ZSBwcm9ncmFtcyBoYWQgYmVlbiB3cml0dGVuIGluIGENCj4gbWVtb3J5LXNhZmUgbGFu Z3VhZ2UuDQo+DQo+IEluIGZhY3QsIG9mIGFsbCB0aGUgQyBidWcgZml4ZXMgdGhhdCBJJ3Zl IGJlZW4gaW52b2x2ZWQgd2l0aCAoYXMNCj4gZWl0aGVyIGF1dGhvciBvciByZXZpZXdlcikg c2luY2UgTWF5LCBhYm91dCB0aHJlZSBxdWFydGVycyBjb3VsZCd2ZQ0KPiBiZWVuIGF2b2lk ZWQganVzdCBieSB1c2luZyBhIGJldHRlciBsYW5ndWFnZS4NCj4NCj4gVGhlIHJlYWwgdGFr ZWF3YXkgaGVyZSBpcyB0aGF0IEMgaXMgbm8gbG9uZ2VyIHN1ZmZpY2llbnQgZm9yIHdyaXRp bmcNCj4gaGlnaCBxdWFsaXR5IGNvZGUgaW4gdGhlIDIwMjBzLiAgRXZlcnlvbmUgbmVlZHMg dG8gYWRhcHQgdGhlaXIgdG9vbHMuDQo+IFByb2dyYW1tZXJzIHdobyBkb24ndCB3aWxsIGlu Y3JlYXNpbmdseSBjb21lIHRvIHJlc2VtYmxlIGV4cGVyaW1lbnRhbA0KPiBhcmNoYWVvbG9n aXN0cywgaS5lLiBwZW9wbGUgd2hvIGxlYXJuIGZsaW50a25hcHBpbmcgdG8gImtlZXAgdGhl DQo+IGtub3dsZWRnZSBhbGl2ZSIuICBTdWNoIHBlb3BsZSBhcmUgdmFsdWFibGUsIGJ1dCBk ZWZpbml0ZWx5IG5pY2hlLiAgSQ0KPiBmb3Igb25lIGRvbid0IHdhbnQgbXkgY2FyZWVyIHRv IGdvIGluIHRoYXQgdHJhamVjdG9yeS4NCg0KSSdtIHNvcnJ5LCB0aGlzIGlzIG5vdCB0aGUg Y29ycmVjdCB0YWtlIGZyb20gaXQuDQoNClRvIGFyZ3VlIHRoYXQgdGhlIGFuc3dlciBpcyB0 byBwdXQgYSBkaWFwZXIgb24gYSBjaGlsZCBzbyBpdCBkb2VzIG5vdCANCmRyb3AgZXhjcmVt ZW50IG9uIHRoZSBjYXJwZXQgaXMgdG8gZm9yZXZlciB0cmVhdCBzYWlkIGh1bWFuIGFzIGFu IGluZmFudCANCndpdGhvdXQgY29udHJvbCBvZiBpdHMgc3BoaW5jdGVycy7CoCBXaGlsZSBz dWNoIGFuIGFuc3dlciBtaWdodCBiZSANCm5lY2Vzc2FyeSBmb3IgYSBzaG9ydCBwZXJpb2Qg b2YgdGltZSBpbiBhbGwgeW91bmcgaHVtYW4gY3JlYXR1cmVzIGl0IA0KYWxzbyBzaG91bGQg YmUgb2J2aW91cyB0aGF0IHdlIGFyZSBhbGwgd2Fsa2luZyBhcm91bmQgdG9kYXkgd2l0aG91 dCB0aGVtIA0KYW5kIHRodXMgc2FpZCBwcm9waHlsYXhpcyBpcyB0byBjb3ZlciBmb3IgYSBk ZWZpY2llbmN5IHJhdGhlciB0aGFuIGEgDQpuZWNlc3NpdHkuDQoNCk5vdyBpZiB0aGUgcHJv cGh5bGF4aXMgaGFkIG5vIGNvc3QgaXQgd291bGRuJ3QgbWF0dGVyIHNvIG11Y2gsIGJ1dCBp dCANCmRvZXMgaGF2ZSBjb3N0IChqdXN0IGFzIGRvIGRpYXBlcnMpIGluIHRoYXQgc3VjaCBs YW5ndWFnZXMgYXJlIA0KaW5oZXJlbnRseSBsZXNzLWVmZmljaWVudC7CoCBUaGVyZSBpcyBh biBhcmd1bWVudCBmb3IgdGhpcyB0cmFkZS1vZmYgDQp3aGVyZSB0aGUgInRoaW5nIiBpcyBp bmZyZXF1ZW50bHkgdXNlZCBhbmQgdGh1cyB0aGUgaW1wYWN0IHNtYWxsLCBidXQgDQpnb2lu ZyB0aGlzIHJvdXRlIGZvciBmcmVxdWVudGx5LXVzZWQgYXBwbGljYXRpb25zIGFuZCBldmVu IHdvcnNlIGF0IHRoZSANCk9TIGxldmVsIGlzIGhvdyB3ZSBnb3QgdG8gYSBwbGFjZSBpbiBt YW55IGFwcGxpY2F0aW9uIHByb2dyYW1zIGFuZCANCm9wZXJhdGluZyBzeXN0ZW1zIHdoZXJl IHdoYXQgdXNlZCB0byBydW4gY29tZm9ydGFibHkgaW4gdW5kZXIgYSBnaWdhYnl0ZSANCm9m IFJBTSB3aWxsIG5vIGxvbmdlciBleGVjdXRlIGF0IGFsbCBpbiBmb3VyLCBhbmQgd2h5IGFu IGFwcGxpY2F0aW9uIA0KKHdoZW4gd3JpdHRlbiBpbiAiQyIpIHdpbGwgaGFuZGxlIG11bHRp cGxlIGNhbWVyYSBzdHJlYW1zIGluIHJlYWwgdGltZSANCndpdGggZml2ZS1taW51dGUgbG9v a2JhY2sgYnVmZmVycywgaGFzIGl0cyBvd24gZGVmZW5zaXZlIHN5c3RlbXMgYWdhaW5zdCAN CmF0dGFjayBhbmQgZGVuaWFsLW9mLXNlcnZpY2UgYW5kIGludGVybmFsIEhUTUwtY2FwYWJs ZSBzZXJ2ZXIgb24gYSAkMjUgDQpwb3N0Y2FyZC1zaXplZCBjb21wdXRlciwgd2VyZSBpdCB0 byBiZSB3cml0dGVuIGluIHN1Y2ggYSAic2FmZSIgbGFuZ3VhZ2UgDQp3b3VsZCBhbHNvIHJl cXVpcmUgYSBkZXZpY2Ugd2l0aCBmaXZlIHRpbWVzIHRoZSBDUFUsIFJBTSAtLSBhbmQgDQpl bGVjdHJpY2FsIGNvbnN1bXB0aW9uIGR1ZSB0byB0aGUgb3ZlcmhlYWQgaW1wb3NlZCBieSBz YW1lLg0KDQpUaHVzIGZvciBrZXJuZWwtbGV2ZWwgb3Igc3lzdGVtLWxpYnJhcnktbGV2ZWwg Y29kZSAob3IgZm9yIHRoYXQgbWF0dGVyIA0KZXhlY3V0aW9uLWhlYXZ5IGFwcGxpY2F0aW9u cykgdGhhdCBhcmUgZXhlY3V0ZWQgdmVyeSBmcmVxdWVudGx5IGFuZCB0aHVzIA0KaW1wb3Nl cyBzYWlkIGNvc3QgYWxsIHRoZSB0aW1lIChvciBhdCBsZWFzdCBhIHZlcnkgbGFyZ2UgYW1v dW50IG9mIHRoZSANCnRpbWUpIHRoZSBkZWJhdGUgb3ZlciAiZG8gaXQgb25jZSBhbmQgZG8g aXQgcmlnaHQsIGV2ZW4gaWYgaXQgdGFrZXMgDQpsb25nZXIgYW5kIHJlcXVpcmVzIHByb2dy YW1tZXJzIG9mIGhpZ2hlciBza2lsbCIgYXBwcm9hY2ggLnZzLiAiZG8gaXQgDQpmYXN0IGFu ZCBsZXQgdGhlIGNvbXB1dGVyIGNhdGNoIGFuZCBmaXggdGhlIHN0dXBpZGl0eSBhdCBydW50 aW1lLCANCmltcG9zaW5nIHNhaWQgY29zdCBpbiBldmVyeSBpbnN0YW5jZSB3aGV0aGVyIHN0 dXBpZGl0eSBvY2N1cnJlZCBpbiB0aGUgDQpjb2Rpbmcgb3Igbm90IiBzaG91bGQgbm90LCBp biBteSBvcGluaW9uIGFueXdheSwgZW5kIGluIHRoZSBsYXR0ZXIgZGVjaXNpb24uDQoNCi0t IA0KS2FybCBEZW5uaW5nZXINCmthcmxAZGVubmluZ2VyLm5ldA0KL1RoZSBNYXJrZXQgVGlj a2VyLw0KL1tTL01JTUUgZW5jcnlwdGVkIGVtYWlsIHByZWZlcnJlZF0vDQo= --------------E8Lf4W0eusc3A0g0SXJ0lQg0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/5/2024 14:09, Alan Somers wrote:<= br> 
By now I expect that most of=
 you have seen the long list of new
security advisories that just came out.  Strikingly, all were the
result of memory handling errors.  And none of them wouldn't have
happened if their respective programs had been written in a
memory-safe language.

In fact, of all the C bug fixes that I've been involved with (as
either author or reviewer) since May, about three quarters could've
been avoided just by using a better language.

The real takeaway here is that C is no longer sufficient for writing
high quality code in the 2020s.  Everyone needs to adapt their tools.
Programmers who don't will increasingly come to resemble experimental
archaeologists, i.e. people who learn flintknapping to "keep the
knowledge alive".  Such people are valuable, but definitely niche.  I
for one don't want my career to go in that trajectory.

I'm sorry, this is not the correct take from it.

To argue that the answer is to put a diaper on a child so it does not drop excrement on the carpet is to forever treat said human as an infant without control of its sphincters.=C2=A0 While such an an= swer might be necessary for a short period of time in all young human creatures it also should be obvious that we are all walking around today without them and thus said prophylaxis is to cover for a deficiency rather than a necessity.

Now if the prophylaxis had no cost it wouldn't matter so much, but it does have cost (just as do diapers) in that such languages are inherently less-efficient.=C2=A0 There is an argument for this trade-off where the "thing" is infrequently used and thus the impact small, but going this route for frequently-used applications and even worse at the OS level is how we got to a place in many application programs and operating systems where what used to run comfortably in under a gigabyte of RAM will no longer execute at all in four, and why an application (when written in "C") will handle multiple camera streams in real time with five-minute lookback buffers, has its own defensive systems against attack and denial-of-service and internal HTML-capable server on a $25 postcard-sized computer, were it to be written in such a "safe" language would also require a device with five times the CPU, RAM -- and electrical consumption due to the overhead imposed by same.

Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not" should not, in my opinion anyway, end in the latter decision.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------E8Lf4W0eusc3A0g0SXJ0lQg0-- --------------3YLnouGggY5YYOvYFDxUunlA-- --------------tz2ZXe8FX0LLJVhK5fWywHIE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEvWWSxnGhSYSUSaCtby3AFeuPWXgFAmbaBHsFAwAAAAAACgkQby3AFeuPWXjO qw/9GmtcB7PvPDc8RkJv6gazdC4yr4IPqiN0U3yIWaR10wYlhkKNY9zD2ohvZBZJ1xAhYBNu+XbX VRjI0oBCbBeDhKtCANVlwB7FWxXUWwSEO19sgQM1vqqGK5dVKQvzZV3YWatY6KSgAIzZj7LS4NLd g4cPyA8AnNbOLrsX0uuXGG3rkFcb9pErT9CuYvikS5+6DbxAN8lMCVhqE1lvj3pS08MsN8Q/dEmU XsIi82sFRwifB75Nty3xsdCWl413+fc2gY1H29V4wNsDyJtkqguTe4u0+x2R1uWdaDGs/vhVCehY 4qoWX6Fv1Q/kwWZ3VE4WeKX9P4Urtd/rP6m4WNbCcmFlntvfpWkPx63jVZVZMw3zWFsUIYVwlnV5 XQn9XdnU9sUBoZcBoayVQzAyvHgX9OrnfCIjHdXEK6GwB6DKoTqicaS7rWEXnV5e4iKqLhyKPHHQ STpVIxmQb7hvTrQl78speQ11Wch5x2QJ+bB1B0RtLVkAqm3f/5V8nIASnG+/ROgYNgMJag2qgiJ3 Kp0rC1P8W1I7tcW3rpOMM2DbiuWGMTIH0yRFReckCr18RXNht3IXuTPo38msZgPsFhyt9G8coJtq N2ltPxz+7H31lEQYKi2pMe9jczwT0GoKWziZfvJf7mdAHfTWuk11uhbQBLQU2TgHnWI4HmFcnveg CSQ= =VJJ7 -----END PGP SIGNATURE----- --------------tz2ZXe8FX0LLJVhK5fWywHIE-- From nobody Thu Sep 5 19:45:29 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 4X08wY1kWJz5TkXC for ; Thu, 05 Sep 2024 19:45:33 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X08wX3BCWz4XcT; Thu, 5 Sep 2024 19:45:32 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725565530; x=1726232196; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=w+ee1NbvgohouKkZRfMnHZRg0gXMB4q6tT2V9zQcrUg=; b=i2sJp4wmleol/zkRLsQA5HvZ1bxtN1fj1Kfm/85bNcpjkPtl/FLxXDelkOuNCscbVwmgP1XR MuYSs1yxXzYOfpKcToRTkUjjBon52mLEouKrbCaa2YElFgpPgc+ZubK4ju0oagTCwAoB2IgJVL WymlIP8Dh3T68D0OrW2mGYQtwU8HiVGhhEvHn9wWQHXj8cJpR4+sVaLYvNwB3tItXT1a8SV/o+ 0NizjSBBd7vzJ2+E+Ti4u0XHjLa4rtgHAmrt4oYbW2eYPiq/iu4HX1fMO5LF69ZhLsnns616XC GwG6hFyGBTNC3FBnaRHkQscNcKhIV08eEb1az1KM6DjwshSw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725565530; x=1726232196; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=w+ee1NbvgohouKkZRfMnHZRg0gXMB4q6tT2V9zQcrUg=; b=VPbxKsc5Z86zkx3WYbESEalmCM4Yq3wlDnNOvHPWzo7f9YlrB6QjCIWXplbtGdqiuctvypIp Pk2V8y0UWr4YDA== Date: Thu, 05 Sep 2024 21:45:29 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Alan Somers Cc: FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: <20240905194529.3szOViVM@steffen%sdaoden.eu> In-Reply-To: References: User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X08wX3BCWz4XcT 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 Alan Somers wrote in : |By now I expect that most of you have seen the long list of new |security advisories that just came out. Strikingly, all were the |result of memory handling errors. And none of them wouldn't have |happened if their respective programs had been written in a |memory-safe language. | |In fact, of all the C bug fixes that I've been involved with (as |either author or reviewer) since May, about three quarters could've |been avoided just by using a better language. | |The real takeaway here is that C is no longer sufficient for writing |high quality code in the 2020s. Everyone needs to adapt their tools. I *totally* speak against this. Quite the opposite i claim that C was safe already fifty years ago, it is just that the occasional one does not realize it. *Nothing* prevents you from using a string object instead of direct memory accesses, a vector object instead of arrays managed via realloc(), and all that. *Nothing*. If *you* do not do that that is your fault and you are a bad programmer; moreover, you should not be allowed to vote in a democratic environment (surely you do not read all the magazines and newspapers, and watch or hear to policital emissions, in order to build yourself a *real* opinion), be enabled to drive a car, and what else not. Ie, please live in a managed environment if you want to. Let me fight for a relatively free language which allows, but does not mandate. I agree that method-on-object is much nicer than pointer-on-function, ie a C++ "str.trim().squeeze().c_str()" is "better" than whatever you do in C. I have no voice anyway and no longer post on this bikeshed midsummer hole stuff. Here are subjects dying, that moves me enough. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Sep 5 19:49:33 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 4X091Q3rvqz5TlXd for ; Thu, 05 Sep 2024 19:49:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X091Q1xZLz4YYf for ; Thu, 5 Sep 2024 19:49:46 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-49bc7387371so359039137.2 for ; Thu, 05 Sep 2024 12:49:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725565785; x=1726170585; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LHv1EHJCKPjT8WTvT1MP8mvKchOvRgKsEylTiWHnHkI=; b=YvrsFRd16NwOziyGLA2AiPBgXQ0azZz8NnzmzkIkwwFcKMsZ+jJ2Q8gr7kBtJHWH1I 29/GmYPQcR/mG0R+/StOgA9dP9Kjek+WLUebt69KO8U/yUceHDlKzj9+uWad9Of14yhg T709I/KO4o4BInpzpOeBP1UNhZc5AIf74/iomKwT3DetCm2svtRS/RBKwmfGQGv2jbor c3AbOmk80etskPgorpf+S51nTn98iveIHs/WYDR6npVp4yrSq9nSAf3XAnN7dECTGhat dg9w/KEL1FeFQz7DfSBLCESTltyzsattN0HBZVIWaQFkavjJ5mtbiIcCkdRtL19nThDo NZfw== X-Gm-Message-State: AOJu0YxNSPlGRFCsHJCTh1lnOa9MJ3g5/qmJvkRFnlrQrvoSJuFLYpIh kGHhnIq4iyAfFWYk7wYhoc9eNrgahObhkx3539xh8Ha+gbhcWk8/uWLq8yUd+l6hdXhDzpIaaPp z7iu4YBpkhOGvk7TcabtFGLnJQYClxZbH X-Google-Smtp-Source: AGHT+IEnDYalboMUPV2HZfg5IUi8WO2FP7fYKPiINHy4E5mO6q78yndhO6+G2rkulK1gak2am7axd50YFT2Pdt7fTs0= X-Received: by 2002:a05:6102:c0b:b0:495:c4e8:fc3f with SMTP id ada2fe7eead31-49a5af48a80mr30271699137.23.1725565785368; Thu, 05 Sep 2024 12:49:45 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Thu, 5 Sep 2024 13:49:33 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Karl Denninger Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X091Q1xZLz4YYf On Thu, Sep 5, 2024 at 1:20=E2=80=AFPM Karl Denninger = wrote: > > On 9/5/2024 14:09, Alan Somers wrote: > > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > I'm sorry, this is not the correct take from it. > > To argue that the answer is to put a diaper on a child so it does not dro= p excrement on the carpet is to forever treat said human as an infant witho= ut control of its sphincters. While such an answer might be necessary for = a short period of time in all young human creatures it also should be obvio= us that we are all walking around today without them and thus said prophyla= xis is to cover for a deficiency rather than a necessity. Do you think that all of those bugs were introduced by novice programmers who hadn't yet learned "control of sphincters"? I don't. They were all professionals. These are the kinds of mistakes that all C programmers make from time to time. No human can write perfect code, no matter how experienced. > > Now if the prophylaxis had no cost it wouldn't matter so much, but it doe= s have cost (just as do diapers) in that such languages are inherently less= -efficient. There is an argument for this trade-off where the "thing" is i= nfrequently used and thus the impact small, but going this route for freque= ntly-used applications and even worse at the OS level is how we got to a pl= ace in many application programs and operating systems where what used to r= un comfortably in under a gigabyte of RAM will no longer execute at all in = four, and why an application (when written in "C") will handle multiple cam= era streams in real time with five-minute lookback buffers, has its own def= ensive systems against attack and denial-of-service and internal HTML-capab= le server on a $25 postcard-sized computer, were it to be written in such a= "safe" language would also require a device with five times the CPU, RAM -= - and electrical consumption due to the overhead imposed by same. I think you are misinformed about the runtime costs involved. In fact, Rust's overhead is quite low. According to the most famous comparison of programming languages, it runs basically at the same speed as C and C++. Rust is often critized for the size of its binaries, but as we've discussed on this list, that's mostly due to the amount of debugging stuff crammed in by default. Those defaults are reasonable for anybody using a modern computer, but embedded developers can easily turn them off. And one of the coolest things about Rust compared to earlier languages like Modula3 is how much of error-checking happens at compile time. It's really quite good. https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summar= y-charts.html > > Thus for kernel-level or system-library-level code (or for that matter ex= ecution-heavy applications) that are executed very frequently and thus impo= ses said cost all the time (or at least a very large amount of the time) th= e debate over "do it once and do it right, even if it takes longer and requ= ires programmers of higher skill" approach .vs. "do it fast and let the com= puter catch and fix the stupidity at runtime, imposing said cost in every i= nstance whether stupidity occurred in the coding or not" should not, in my = opinion anyway, end in the latter decision. Bugs like this are quite frequent in the FreeBSD code base. So by your logic, we must not have "programmers of higher skill" and therefore we should be relying on more advanced programming languages to "fix the stupidity". Point taken. From nobody Thu Sep 5 19:49:34 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 4X091V2YNsz5TlV3 for ; Thu, 05 Sep 2024 19:49:50 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R11" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X091V0XrRz4YWp; Thu, 5 Sep 2024 19:49:49 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 485JnZO9045955 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 Sep 2024 15:49:41 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <720947e9-ef58-4f3f-9b5f-09b5930800b0@m5p.com> Date: Thu, 5 Sep 2024 15:49:34 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Alan Somers , FreeBSD Hackers References: Content-Language: en-US From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------9dMHoY8qw4hlDU3ARxhiu9lg" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[freebsd]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US] X-Rspamd-Queue-Id: 4X091V0XrRz4YWp This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9dMHoY8qw4hlDU3ARxhiu9lg Content-Type: multipart/mixed; boundary="------------TbhF0b8FcyiN0UdynaqlIiYQ"; protected-headers="v1" From: George Mitchell To: Alan Somers , FreeBSD Hackers Message-ID: <720947e9-ef58-4f3f-9b5f-09b5930800b0@m5p.com> Subject: Re: The Case for Rust (in any system) References: In-Reply-To: --------------TbhF0b8FcyiN0UdynaqlIiYQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS81LzI0IDE0OjA5LCBBbGFuIFNvbWVycyB3cm90ZToNCj4gQnkgbm93IEkgZXhwZWN0 IHRoYXQgbW9zdCBvZiB5b3UgaGF2ZSBzZWVuIHRoZSBsb25nIGxpc3Qgb2YgbmV3DQo+IHNl Y3VyaXR5IGFkdmlzb3JpZXMgdGhhdCBqdXN0IGNhbWUgb3V0LiAgU3RyaWtpbmdseSwgYWxs IHdlcmUgdGhlDQo+IHJlc3VsdCBvZiBtZW1vcnkgaGFuZGxpbmcgZXJyb3JzLiAgQW5kIG5v bmUgb2YgdGhlbSB3b3VsZG4ndCBoYXZlDQo+IGhhcHBlbmVkIGlmIHRoZWlyIHJlc3BlY3Rp dmUgcHJvZ3JhbXMgaGFkIGJlZW4gd3JpdHRlbiBpbiBhDQo+IG1lbW9yeS1zYWZlIGxhbmd1 YWdlLg0KDQpzL3dvdWxkbid0L3dvdWxkLyA/DQoNCj4gDQo+IEluIGZhY3QsIG9mIGFsbCB0 aGUgQyBidWcgZml4ZXMgdGhhdCBJJ3ZlIGJlZW4gaW52b2x2ZWQgd2l0aCAoYXMNCj4gZWl0 aGVyIGF1dGhvciBvciByZXZpZXdlcikgc2luY2UgTWF5LCBhYm91dCB0aHJlZSBxdWFydGVy cyBjb3VsZCd2ZQ0KPiBiZWVuIGF2b2lkZWQganVzdCBieSB1c2luZyBhIGJldHRlciBsYW5n dWFnZS4NCj4gDQpBbiBhdHRyYWN0aXZlIHByb3Bvc2l0aW9uIC0tIGlmIHdlIGNvdWxkIG9u bHkgZ2V0IHVuaXZlcnNhbCBjb25zZW5zdXMNCm9uICJhIGJldHRlciBsYW5ndWFnZS4iDQoN Cj4gVGhlIHJlYWwgdGFrZWF3YXkgaGVyZSBpcyB0aGF0IEMgaXMgbm8gbG9uZ2VyIHN1ZmZp Y2llbnQgZm9yIHdyaXRpbmcNCj4gaGlnaCBxdWFsaXR5IGNvZGUgaW4gdGhlIDIwMjBzLiAg Wy4uLl0NCj4gVG8gc3VtbWFyaXplLCBoZXJlJ3MgdGhlIGxpc3Qgb2YgdGhpcyB3ZWVrJ3Mg c2VjdXJpdHkgYWR2aXNvcmllcywgYW5kDQo+IGFsc28gc29tZSBvdGhlciByZWNlbnQgQyBi dWcgZml4ZXMgb2YgbXkgb3duIGludm9sdmVtZW50Og0KPiANCj4gWy4uLiBhbiBhbGFybWlu Z2x5IGxvbmcgbGlzdCBvZiByZWdyZXR0YWJsZSBsYXBzZXMgLi4uXQ0KDQpZb3UndmUgYWN0 dWFsbHkgZ290IG1lIHRoaW5raW5nIHNlcmlvdXNseSBhYm91dCB0aGlzLiAgVGhhbmsgeW91 IQ0KSSBkb24ndCB5ZXQga25vdyBlbm91Z2ggYWJvdXQgcnVzdCB0byBhc3Nlc3Mgd2hldGhl ciBpdCdzIHRoZSBwYW5hY2VhDQphIGxvdCBvZiBwZW9wbGUgYmVsaWV2ZSBpdCB0byBiZS4g IEkga2luZCBvZiBkb3VidCBpdCBnaXZlbiB0aGUgcXVhbG1zDQp0aGF0IGhhdmUgYmVlbiBl eHByZXNzZWQuDQoNCkJ1dCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gc2l4IHllYXJzIG9mIHJl dGlyZW1lbnQgZnJvbSBhIGZpZnR5LXllYXINCmNhcmVlciBpbiB3cml0aW5nIHByb2dyYW1z LCBhbmQgbm90aGluZyBlbHNlLCB5b3UgaGF2ZSBjYXVnaHQgbXkNCmludGVyZXN0IGluIHRo ZSBwb3NzaWJpbGl0eSBvZiBmaWdodGluZyB0aGVzZSBzdHVwaWQgZXJyb3JzIHdlIGhhdmUN CmFsbCBtYWRlLiAgUGxlbnR5IG9mIHRpbWVzLCBldmVuIGluIG15IG93biBjYXNlISAgICAg ICAgICAgIC0tIEdlb3JnZQ0K --------------TbhF0b8FcyiN0UdynaqlIiYQ-- --------------9dMHoY8qw4hlDU3ARxhiu9lg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZtoLTgUDAAAAAAAKCRCaHA937rZnfYEV AQC8r2BSkLGynwTcGjsxuCh/WjZ7FIOibjVXOj4WyIb26wEA1uJwGgAFErE7Tk225sEPESGVU9IF z4cSx8yi4C4ccgo= =0Xpi -----END PGP SIGNATURE----- --------------9dMHoY8qw4hlDU3ARxhiu9lg-- From nobody Thu Sep 5 19:55:56 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 4X098Z0dqjz5TmVY for ; Thu, 05 Sep 2024 19:55:58 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X098Y5ZSlz4c3H for ; Thu, 5 Sep 2024 19:55:57 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 95707 invoked by uid 89); 5 Sep 2024 19:55:56 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 5 Sep 2024 19:55:56 -0000 Message-ID: Date: Thu, 5 Sep 2024 15:55:56 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Alan Somers , FreeBSD Hackers References: Content-Language: en-US From: Jan Knepper In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X098Y5ZSlz4c3H Was any of this code run through any static analyzer or anything like that recently? And literally all of these were missed? On 9/5/24 14:09, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: > > Buffer overflow > =============== > https://cgit.freebsd.org/src/commit/?id=3aaaca1b51ad844ef9e9b3d945217ab3dd189bae > CVE-2024-45288 FreeBSD-SA-24:09.libnv > https://cgit.freebsd.org/src/commit/?id=a06fc21e770a482c8915411ebc98c870e42dd29b > CVE-2024-41928 FreeBSD-SA-24:10.bhyve > https://cgit.freebsd.org/src/commit/?id=af438acbfde3d25dbdc82b2b3d72380f0191e9d9 > CVE-2024-42416 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=db87c98168b1605f067d283fa36a710369c3849d > FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=5c9308a4130858598c76f3ae6e3e3dfb41ccfe68 > CVE-2024-32668 FreeBSD-SA-24:12.bhyve > > Integer overflow > ================ > https://cgit.freebsd.org/src/commit/?id=36fa90dbde0060aacb5677d0b113ee168e839071 > CVE-2024-45287 FreeBSD-SA-24:09.libnv > https://cgit.freebsd.org/src/commit/?id=c3e6dfe55c0e81d0717b0458bc95128384c3ebe8 > FreeBSD-SA-24:14.umtx > > Use after free > ============== > https://cgit.freebsd.org/src/commit/?id=670b582db6cb827a8760df942ed8af0020a0b4d0 > CVE-2024-45063 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 > CVE-2024-43102 FreeBSD-SA-24:14.umtx > > Uninitialized memory access > =========================== > https://cgit.freebsd.org/src/commit/?id=ea44766b78d639d3a89afd5302ec6feffaade813 > CVE-2024-8178 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=0f2b2276abc305905e7d88619a7abca26b0dd7eb > > Memory Leaks > ============ > https://cgit.freebsd.org/src/commit/?id=2909ddd17cb4d750852dc04128e584f93f8c5058 > > Incorrect union member access > ============================= > https://cgit.freebsd.org/src/commit/?id=9a5a7c90d5e5971fe2b9c9265e9279a6f173a8f3 > CVE-2024-6119 FreeBSD-SA-24:13.openssl > > Concurrent unsychronized memory access > ====================================== > https://cgit.freebsd.org/src/commit/?id=1f5bf91a85e93afa17bc9c03fe7fade0852da046 > > RAII > ==== > https://cgit.freebsd.org/src/commit/?id=4b3141f5d5373989598f9447ab5a9f87e2d1c9fb > > Unchecked errors [^1] > ====================== > https://cgit.freebsd.org/src/commit/?id=35f4984343229545881a324a00cdbb3980d675ce > https://cgit.freebsd.org/src/commit/?id=eced2e2f1e56b54753702da52a88fccbe73b3dcb > https://cgit.freebsd.org/src/commit/?id=f625d038d2ae59fa1ae81b76079da464ed6db61a > > Not preventable by a safer programming language > =============================================== > https://cgit.freebsd.org/src/commit/?id=7d6932d20aedbbb220cd78e90ab4e82d1abaad31 > https://cgit.freebsd.org/src/commit/?id=6efba04df3f8c77b9b12f1df3e5124a7249b82fc > https://cgit.freebsd.org/src/commit/?id=4b72bab96e8978eaed30fd44f7f51e1b4918d4db > https://cgit.freebsd.org/src/commit/?id=b64afa41d56e98b5817aaf14c7deb0fa7e2142fb > > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. > From nobody Thu Sep 5 19:55:32 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 4X09Lp0vCFz5TnpK for ; Thu, 05 Sep 2024 20:04:50 +0000 (UTC) (envelope-from dsl@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 4X09Lp0Js9z4fK5; Thu, 5 Sep 2024 20:04:50 +0000 (UTC) (envelope-from dsl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725566690; 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=7f10AHTgO0UrlGr8v4Vh6yRFBlCtBtfyVTpAfEcEzh4=; b=c1wejJusdTnZiuikGP+3mmZTHNF1HYvgWNdsqpT7Z8gERDadHzlqfDBXfb9n6J1TJGbK4a KbnSE49PBB+JTuh5UoOuWeg7Xtd5qBVXyBT4oGOud/4fCuvp5u+sOinRjHITK9vmMxs3Tl mBMsZy+Tqv1+kLdnGgCsZ2/hHyYGI5wQ8z9FpH+zuADDcPnLoa5d3zRaluy/v60fByfEfq fDjEfJdnSnIVUEiEEBe4TQFN+0gXrNqk6kdHt7DCsignHs+UnXbt9VhXSONt4lAHqyW4MI 18ggIS6a699gAOas149pM48u9AXjlb9XieXcm0Iz2GKdUV1W7HSxJTZ2RbKAzg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725566690; a=rsa-sha256; cv=none; b=xVQ3D6N0tlyi5ajHUWt5XqIQRmp554dNAHUqH03DCC5qO2sWR11HDOec9QysYTD8EmJMtj 8K7P1LrpjiMsR40uzyUAWN2KxLokZcliN/E1ZjnOBmOeFRAHI0re33t3ZdLcWt5HYCyocE C9mWTRnB+CQCQHlyOohZs23CzjMeWI7aDI6pIPAvv8AY2UI4bAPZ/cJgYEGEDp6V8fPD0x ACOo9Nod7CCYvRcTOw8YJMG12GWVomTgwk0N5xHRug8hv2XSJVaBy8kC845njmhsnQ/sPS gHij8Mx/wCL3XlTbkiaLcC1L8VVdHB+45Icnj57sXYgYbqtcRuujyI5FEr0Zcw== 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=1725566690; 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=7f10AHTgO0UrlGr8v4Vh6yRFBlCtBtfyVTpAfEcEzh4=; b=rs+AxZUZzxLXsOoREbTDXX9akP7YExdSX0Ji3/gHQdj5EbegOSEWMAD8KSRJm5Scm0bkfn R8XMKZ/s7lRNlKZuKU9i2c3APOP6PJA1vjg2dVqqHFHMGch2tZwWnzwS2BCc5Z8a73SJdK RiM56sl+sTaCvw5gZEyCG0CliE5vQI5QXrcMRObYuQDkYEnOq76MIzBVWSlfhm5HqVNs4i Ar7uDAA+nXwySMYPMxJIaQbJQ1lu9ok2fQQgsCDkL8geJxXtqYZwbxZHbhu6ppeGq3Eo66 BGmj+Mcq8Q+ei64cwbn6NgYsltDF0bMZ3Px01LlvFY9UDFKOB64pUCbIXBgk3A== Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dsl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X09Ln4xBkz1HYq; Thu, 5 Sep 2024 20:04:49 +0000 (UTC) (envelope-from dsl@FreeBSD.org) References: User-agent: mu4e 1.8.13; emacs 29.4 From: Dmitry Salychev To: Karl Denninger Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Thu, 05 Sep 2024 21:55:32 +0200 In-reply-to: Message-ID: <86bk1150kh.fsf@peasant.bootbsd.com> 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: text/plain Karl Denninger writes: > [[PGP Signed Part:Undecided]] > On 9/5/2024 14:09, Alan Somers wrote: > > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > I'm sorry, this is not the correct take from it. > > To argue that the answer is to put a diaper on a child so it does not drop excrement on the carpet is to forever treat said > human as an infant without control of its sphincters. While such an answer might be necessary for a short period of time in > all young human creatures it also should be obvious that we are all walking around today without them and thus said > prophylaxis is to cover for a deficiency rather than a necessity. > > Now if the prophylaxis had no cost it wouldn't matter so much, but it does have cost (just as do diapers) in that such > languages are inherently less-efficient. There is an argument for this trade-off where the "thing" is infrequently used and thus > the impact small, but going this route for frequently-used applications and even worse at the OS level is how we got to a place > in many application programs and operating systems where what used to run comfortably in under a gigabyte of RAM will no > longer execute at all in four, and why an application (when written in "C") will handle multiple camera streams in real time with > five-minute lookback buffers, has its own defensive systems against attack and denial-of-service and internal HTML-capable > server on a $25 postcard-sized computer, were it to be written in such a "safe" language would also require a device with five > times the CPU, RAM -- and electrical consumption due to the overhead imposed by same. > > Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very > frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and > do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer > catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not" > should not, in my opinion anyway, end in the latter decision. Well said. Personally, I wouldn't argue that people tend to do stupid thing with the tools given, but putting everyone in diapers is just _one_ possible way to solve the problem. If Rust is somehow considered to be brought deep down in the FreeBSD kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and MISRA C++:2023. Regards, Dmitry -- https://wiki.freebsd.org/DmitrySalychev From nobody Thu Sep 5 20:12:58 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 4X09XC2PlBz5TpxW for ; Thu, 05 Sep 2024 20:12:59 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X09XC1mXxz4h3b for ; Thu, 5 Sep 2024 20:12:59 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 98882 invoked by uid 89); 5 Sep 2024 20:12:58 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 5 Sep 2024 20:12:58 -0000 Content-Type: multipart/alternative; boundary="------------tn8atr0Z1Z8NOIGhNObB7LaE" Message-ID: <00e1d94b-7484-4cc1-97ef-dabf801f65d5@digitaldaemon.com> Date: Thu, 5 Sep 2024 16:12:58 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Dmitry Salychev , Karl Denninger Cc: freebsd-hackers@freebsd.org References: <86bk1150kh.fsf@peasant.bootbsd.com> Content-Language: en-US From: Jan Knepper In-Reply-To: <86bk1150kh.fsf@peasant.bootbsd.com> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X09XC1mXxz4h3b This is a multi-part message in MIME format. --------------tn8atr0Z1Z8NOIGhNObB7LaE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/5/24 15:55, Dmitry Salychev wrote: > Karl Denninger writes: > >> [[PGP Signed Part:Undecided]] >> On 9/5/2024 14:09, Alan Somers wrote: >> >> By now I expect that most of you have seen the long list of new >> security advisories that just came out. Strikingly, all were the >> result of memory handling errors. And none of them wouldn't have >> happened if their respective programs had been written in a >> memory-safe language. >> >> ... >> Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very >> frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and >> do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer >> catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not" >> should not, in my opinion anyway, end in the latter decision. > Well said. > > Personally, I wouldn't argue that people tend to do stupid thing with > the tools given, but putting everyone in diapers is just _one_ possible > way to solve the problem. > > If Rust is somehow considered to be brought deep down in the FreeBSD > kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and > MISRA C++:2023. > Agreed... And use code analyzers/static analyzers.. I have not worked with Coverity recently, but when we did, it was pretty good what it found & reported. We had to convince that the $50K/year or $100K/year price tag, what ever it was, was worth it because Coverity would do for a price per year what we could not hire anyone to do for us with the same consistency, speed, and accuracy. There are several others. More and more, these type of tools are being integrated into modern day compiler tool-chains. Use them! --------------tn8atr0Z1Z8NOIGhNObB7LaE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 9/5/24 15:55, Dmitry Salychev wrote:
Karl Denninger <karl@denninger.net> writes:


[[PGP Signed Part:Undecided]]
On 9/5/2024 14:09, Alan Somers wrote:

 By now I expect that most of you have seen the long list of new
security advisories that just came out.  Strikingly, all were the
result of memory handling errors.  And none of them wouldn't have
happened if their respective programs had been written in a
memory-safe language.

...
Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very
frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and
do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer
catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not"
should not, in my opinion anyway, end in the latter decision.

Well said.

Personally, I wouldn't argue that people tend to do stupid thing with
the tools given, but putting everyone in diapers is just _one_ possible
way to solve the problem.

If Rust is somehow considered to be brought deep down in the FreeBSD
kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and
MISRA C++:2023.
Agreed...

And use code analyzers/static analyzers..

I have not worked with Coverity recently, but when we did, it was pretty good what it found & reported.
We had to convince that the $50K/year or $100K/year price tag, what ever it was, was worth it because Coverity would do for a price per year what we could not hire anyone to do for us with the same consistency, speed, and accuracy.

There are several others.

More and more, these type of tools are being integrated into modern day compiler tool-chains.

Use them!


--------------tn8atr0Z1Z8NOIGhNObB7LaE-- From nobody Thu Sep 5 20:16:45 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 4X09cp2Grxz5Tq7x for ; Thu, 05 Sep 2024 20:16:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X09cp0Tfbz4jbp for ; Thu, 5 Sep 2024 20:16:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2d87196ec9fso906040a91.1 for ; Thu, 05 Sep 2024 13:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725567417; x=1726172217; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nUFLiuJWjnfZLIxUhTAqDPAko5nOj9B0cIZ1H/3ZdxY=; b=SKbGESKjkANlSLy6m15/g7zgdQv4Ogd3Sl4I8OpUNifpjLo8ZE78y05M/PXvZJ4c99 idrS19pOn8sJMC22O27VkXGz3TXs0p22sO/utwwNo2Uq80bbcj/ZSqJC1K0htK3Ab3mv xLO8roR/a4QDQJw4fXbJ9GRHy9jY0mOBICD078xSOryzWkN0DZ4hf+54pDzZa4uQlW+z ZQpa2d9UJ7m0tRNnwRN7QRB1jBq3QiVy+xigp11QuavMqGKE120whghz+QDANi6ezlU+ uWB59sOHAeHVrO84/4HJj1N45m5ukm7AxKsNEud3sVx13cr3XQ2IKYChRnb0L6Q1jgex HBtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725567417; x=1726172217; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nUFLiuJWjnfZLIxUhTAqDPAko5nOj9B0cIZ1H/3ZdxY=; b=UH3JcyKflr+w976HP5bAvBUH83jbWoFuNL+LuFuYX67rEJPF212wBVVkSiNyFgeh9C s6qR3PBjP0DZSLn+E7Iw58Yj9FLUCj+1u193LrFuJHcQPJ1C79gK/iiQzLlfDJxXeuZS t8tnlmK8+eJK2AdVl91XKOqDxgkGFE8JQhLpzmDfe048guvwcTpXpquvK6s12JKO/t1T wRkOoSPlH4MOSC8+tQeEZgqGWFkQpuINFUYk4Y4noOLjW6cbv6dulG6XFSJDEWCJCyui ppc/OniNLFmsB5je44i0nE6Z4Uz/BYpDekNAtHK6ISp4lw6YRWbK+A3UMOtOD5BXIC3R FM+w== X-Gm-Message-State: AOJu0YyD1xP2/Zfze/K8bb/LJz3nLas2WgkX6KgdIDwXoF42h0EVXvFD 3cbecurer96MlmymmWzh1Mleli4fapRi7g/sYApDxEAo8ox/q1F57pZ2rzfpJaW9EfyTWU15s75 jFBlh1GOwDMO/E0w1FbxruPVntLTvL7nScBZSC5LR4G+HJwxL X-Google-Smtp-Source: AGHT+IGGNWhvh2z9Ua46q+ra7qW4Guz1XukS3pzK29Y6JqOiQYbefV9jFaa0UizKUCsUM/7Lynyj/uz9VhBjBoei/DE= X-Received: by 2002:a17:90b:3e8a:b0:2cf:c9ab:e747 with SMTP id 98e67ed59e1d1-2dad4de4d19mr655365a91.1.1725567416518; Thu, 05 Sep 2024 13:16:56 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Thu, 5 Sep 2024 14:16:45 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e5e46d062164f8cc" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X09cp0Tfbz4jbp --000000000000e5e46d062164f8cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers w= rote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > FreeBSD represents hundreds of thousands or millions of man hours in its current form (depending on how you measure it). It has evolved over 30 years. To get to the same level of maturity in a rust rewrite would take a similar amount of time. But even if it took an order of magnitude less because rust is that much better, that represents a huge pool of manpower that don't seem to be hanging out around the project just waiting for something to do. Where do the resources for this come from? Without enough resources, the rewrites will be crap and nobody will want to use them (or maybe even FreeBSD). The rewrites to date have lost functionality (though maybe not functionality that's important) relative to what they replace. So great, we should switch to rust. But so far we have no way to do that incrementally (other than a parallel build system, which isn't very FreeBSDish). And if we can't even find the resources to do that minimal level of work, how can the rest possibly be robustly undertaken? Warner --000000000000e5e46d062164f8cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 5, 2024 at 12:10=E2=80=AF= PM Alan Somers <asomers@freebsd.o= rg> wrote:
knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: > > Buffer overflow > =============== > https://cgit.freebsd.org/src/commit/?id=3aaaca1b51ad844ef9e9b3d945217ab3dd189bae > CVE-2024-45288 FreeBSD-SA-24:09.libnv > https://cgit.freebsd.org/src/commit/?id=a06fc21e770a482c8915411ebc98c870e42dd29b > CVE-2024-41928 FreeBSD-SA-24:10.bhyve > https://cgit.freebsd.org/src/commit/?id=af438acbfde3d25dbdc82b2b3d72380f0191e9d9 > CVE-2024-42416 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=db87c98168b1605f067d283fa36a710369c3849d > FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=5c9308a4130858598c76f3ae6e3e3dfb41ccfe68 > CVE-2024-32668 FreeBSD-SA-24:12.bhyve > > Integer overflow > ================ > https://cgit.freebsd.org/src/commit/?id=36fa90dbde0060aacb5677d0b113ee168e839071 > CVE-2024-45287 FreeBSD-SA-24:09.libnv > https://cgit.freebsd.org/src/commit/?id=c3e6dfe55c0e81d0717b0458bc95128384c3ebe8 > FreeBSD-SA-24:14.umtx > > Use after free > ============== > https://cgit.freebsd.org/src/commit/?id=670b582db6cb827a8760df942ed8af0020a0b4d0 > CVE-2024-45063 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 > CVE-2024-43102 FreeBSD-SA-24:14.umtx > > Uninitialized memory access > =========================== > https://cgit.freebsd.org/src/commit/?id=ea44766b78d639d3a89afd5302ec6feffaade813 > CVE-2024-8178 FreeBSD-SA-24:11.ctl > https://cgit.freebsd.org/src/commit/?id=0f2b2276abc305905e7d88619a7abca26b0dd7eb > > Memory Leaks > ============ > https://cgit.freebsd.org/src/commit/?id=2909ddd17cb4d750852dc04128e584f93f8c5058 > > Incorrect union member access > ============================= > https://cgit.freebsd.org/src/commit/?id=9a5a7c90d5e5971fe2b9c9265e9279a6f173a8f3 > CVE-2024-6119 FreeBSD-SA-24:13.openssl > > Concurrent unsychronized memory access > ====================================== > https://cgit.freebsd.org/src/commit/?id=1f5bf91a85e93afa17bc9c03fe7fade0852da046 > > RAII > ==== > https://cgit.freebsd.org/src/commit/?id=4b3141f5d5373989598f9447ab5a9f87e2d1c9fb > > Unchecked errors [^1] > ====================== > https://cgit.freebsd.org/src/commit/?id=35f4984343229545881a324a00cdbb3980d675ce > https://cgit.freebsd.org/src/commit/?id=eced2e2f1e56b54753702da52a88fccbe73b3dcb > https://cgit.freebsd.org/src/commit/?id=f625d038d2ae59fa1ae81b76079da464ed6db61a > > Not preventable by a safer programming language > =============================================== > https://cgit.freebsd.org/src/commit/?id=7d6932d20aedbbb220cd78e90ab4e82d1abaad31 > https://cgit.freebsd.org/src/commit/?id=6efba04df3f8c77b9b12f1df3e5124a7249b82fc > https://cgit.freebsd.org/src/commit/?id=4b72bab96e8978eaed30fd44f7f51e1b4918d4db > https://cgit.freebsd.org/src/commit/?id=b64afa41d56e98b5817aaf14c7deb0fa7e2142fb > > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. > From nobody Thu Sep 5 20:20:23 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 4X09hr4S4tz5TqKj for ; Thu, 05 Sep 2024 20:20:28 +0000 (UTC) (envelope-from christos@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 4X09hr2z0Kz4lRy; Thu, 5 Sep 2024 20:20:28 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725567628; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Li+XrZyN/H4GrbzZYAAT9hYw0V88vZAAWqrlgbA9aKY=; b=qZy5CiDc5Fg1Svq4vzkw9OzNjXLT1vs4uCJfqRaSvoQWVOtys2AR1sKkLNTAoVs8npCE2M 7rK1ycewpywWFgwVVZZtywNZXH+A6U54A9f++6izda2xGdRkmrL/7GiT0elR/PH7O7y7gl 2pjHRpNDyhtcQft44rJ7MJYrQvIFAnQhSZOpP5Vsszl3fe/p9L3aZtebx4LcwJwjy+/yW5 OZhDU9d5pIwLv8lHG9Wy6V32PtA+GJHmMF/EeBlEP8jT08v4rpr+VCq2rgUdHcEE57M1FM M9Xt9ow9p8meBRw7jYgEf+ejllxc4GPHbCq5dtmfmOBk6Q87XFVqlOHwM36zGA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725567628; a=rsa-sha256; cv=none; b=lUX/WTKjE+d3ychQBdqaOehRgE7TMxOyKWypzH3s34s5W/jKSr444QVes3G8r2NbEUJCIz nqusLaJW6gjyuFn9gsHt7Dt1/rx9mz2u5G7wDFXvSTH1mMRFYwRGnpHTexO521PZkdmk3K dCtdJDc6QmfvJPfGbB0CbI2/ihyHyP0Fbx6/AYL8TP/B4Y3qDn1Cr9G2YUAHece/OxYEo8 yZt3i4OM/2rlcSuUEME8XCrFZHGcGJFkP2/F3ylNvGleYSuZONpYX/Z3Bun3aUU0ILqV7F OLJrIR5KlJGYEwLid1ftbm53LI2yYOFHIDFxr19wnUwcZjjQBabHvd90E1GRrw== 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=1725567628; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Li+XrZyN/H4GrbzZYAAT9hYw0V88vZAAWqrlgbA9aKY=; b=FmhR8ugAYDtOJqtvKNT+gmSs98pBnZ9xE6uhrhpVid5EcpTdiZl7Xmji4MLd6pKW1rXOD9 SEeZzfNvHW7TmiDBvFo50s83mlFKiO3PtcOPYL6jpGFdP/xJdqJhrlBMus0om28KvlZkaB 28PKhO3hgiVyER/cuTvJB9oVEUknNb6jrHgCbio9VXAPkBb5HPwWaq0n3zVQlTRimzuQ4a BonVsXItpM63GVNV9sNjqzxVA10+68zo0nIWtWr8RSvPf3a6k2GT2FTsFQsrsgEDrZlnh5 x9AbBXai1lLcP5ZLQ2QG6ugwtdtG1NNOm1+uHpjTFC1SxVrNGpcrnJGLBuy1dA== Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: christos/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X09hq6pPRz1HZ5; Thu, 5 Sep 2024 20:20:27 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=OZgeaB1wIogQpHc 2UnfkxuHrUfKlvBhqUOcJz4eFUaY=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=hMBgk4/iBGfPRi0YW+228SnmhnOhshQcHUYF29xH fxhHcBc4z7pBqIFqFpNr3lanr8+YKZ1ugZqHuD4mDydDaaXiChQQpC06/kyBCnudqHNuVt nJ95uXnnDFfc7FRcQ84BKJhckJL93tFRyhi2pTMmXFTHwOt0urr5UQ7yCOOn0= Received: from tpad (31-217-173-192.cgn.acro.cosmote.net [31.217.173.192]) by margiolis.net (OpenSMTPD) with ESMTPSA id df6cf140 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 5 Sep 2024 20:20:25 +0000 (UTC) Date: Thu, 5 Sep 2024 23:20:23 +0300 From: Christos Margiolis To: Warner Losh Cc: Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: References: 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Warner Losh wrote: > On Thu, Sep 5, 2024 at 12:10 PM Alan Somers wrote: > > > By now I expect that most of you have seen the long list of new > > security advisories that just came out. Strikingly, all were the > > result of memory handling errors. And none of them wouldn't have > > happened if their respective programs had been written in a > > memory-safe language. > > > > FreeBSD represents hundreds of thousands or millions of man hours > in its current form (depending on how you measure it). It has evolved > over 30 years. To get to the same level of maturity in a rust rewrite would > take a similar amount of time. But even if it took an order of magnitude > less because rust is that much better, that represents a huge pool of > manpower that don't seem to be hanging out around the project just > waiting for something to do. > > Where do the resources for this come from? Without enough resources, > the rewrites will be crap and nobody will want to use them (or maybe even > FreeBSD). The rewrites to date have lost functionality (though maybe not > functionality that's important) relative to what they replace. > > So great, we should switch to rust. But so far we have no way to do that > incrementally (other than a parallel build system, which isn't very > FreeBSDish). > And if we can't even find the resources to do that minimal level of work, > how > can the rest possibly be robustly undertaken? I second that. Christos From nobody Thu Sep 5 20:21:51 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 4X09kj5GvGz5TqqJ for ; Thu, 05 Sep 2024 20:22:05 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X09kj3YlQz4mdG for ; Thu, 5 Sep 2024 20:22:05 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-71790698b22so143593b3a.1 for ; Thu, 05 Sep 2024 13:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1725567724; x=1726172524; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7f1uCPIAYkZHdvYd8IMaObZTiYZHBR6C8TYfGojEiPo=; b=fOc/d+qF1lMUWCIUAN2EV1GsJmlNNODVupob6orF/gqFh2vXlDqmjNxvNQWEpuAsLj 5FkSVh+pGDH3lYiRz6/96dx05OLp8aj4pShZQffjSWU+esibkKydmrmz6d4OIrjZWKFD VnhUELILIXa9CMwSGivluu7UDivsdO0jihTJ6zBYF8lubOo3094RjkaDPrrvbqEBZJzH DEV6ZnsVJT7dwHFBfCQjcU5km9ueZ3zqXOwJrMKGhJMFKfQ8BnRcVVg1NkViJV4ojPKg ZQA2ufX2E8f806k9NdDm01xH9l3QnOOSgvpRKsXY2Nu39WJGcnt4qR1gVTvM/d83Lov8 5ExA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725567724; x=1726172524; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7f1uCPIAYkZHdvYd8IMaObZTiYZHBR6C8TYfGojEiPo=; b=dUbQ1PBjjn478k1Owu973jHzyYpbWa6OOiVYlLr1RybffOOUdNLYoAuFSkIuMsSzeN rRcwVr4O30gcTHBywl7wv4Pd2t6unzUGflTDab/Xd71iPASpRqX3gnrNCFbjjW2pCyLD gBPBsKzUlFlj/7cH009YBjHWHy6flmsmKDs+eJ8iiy9p0XG06RDvChL8zn6p1ugnlEjX o530n7t3ovOB+gQ9ovIyKQKplA30xDhO2zV+Ryj3jzmP1q9+mRAtZ5SSRNUElZv2/yal 8lhDQBbCiUiNM4+Bhmc6dJkvJmIGVapA6Yl98uwEeHgniAxvb3VQqt9ktV7BPyJhDrQs lVpQ== X-Forwarded-Encrypted: i=1; AJvYcCVuc42Z5okkBDam2iDX9wDI4aoC4dexCinngp/qqVn75CJgg4NiQAcNwDpUoLx6zoYX+CZmnOI1dD2jJ3D+c1U=@freebsd.org X-Gm-Message-State: AOJu0YyfOMeDXe1yrNp9X8Wc3PsDpXkLCf8vZ+m5NzdEfIyE0/akjaMm ll7Y1wUw+ANn1loMRJOJydTHM/pAnjT835CDFodvnMnPEx2phd6oG5y6Auvnuw== X-Google-Smtp-Source: AGHT+IEX3wefZezq3e65gnxIwGNWd4lLvQHtr2E+TOWgpChzWhPRStjyWU5r2L3mdwV0snglOOY8Lg== X-Received: by 2002:a17:902:ce8b:b0:205:76f3:fc22 with SMTP id d9443c01a7336-206f051f759mr1568035ad.3.1725567723519; Thu, 05 Sep 2024 13:22:03 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-206aea69ad8sm32258865ad.287.2024.09.05.13.22.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2024 13:22:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) From: Bakul Shah In-Reply-To: Date: Thu, 5 Sep 2024 13:21:51 -0700 Cc: Alan Somers , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <4634B979-4EB9-41AE-A9FE-14ACC9A4324A@iitbombay.org> References: To: Tomek CEDRO X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X09kj3YlQz4mdG On Sep 5, 2024, at 11:34=E2=80=AFAM, Tomek CEDRO = wrote: >=20 > wow! this is undeniable argument even for someone who opposes the idea = (like me) :-) Not really! Showing that a present system has issues does not imply in any way that a proposed new system (or major change) will fix the said problems! This is a common fallacy that people fall for. Many people. Many many people :-) Nor does it say anything about the cost & disruption of making such a change, or how long will it take for the change to realize the promise. I did a quick check to see how code size has increased (just focusing on the kernel): Snapshot LoC R2.1.0: 464163 R3.1.0: 1036969 R4.1.0: 1364739 R5.1.0: 2183960 R6.1.0: 2718891 R7.1.0: 3396813 R8.1.0: 4029778 R9.1.0: 5436430 R10.1.0: 6268965 R11.1.0: 7902854 R12.1.0: 8216741 R13.1.0: 8900711 R14.1.0: 9769864 current: 9899932 (as of this morning) On average about 775K lines are added per release, with a couple of increases over a million. So even if *all* the new code that gets added is in Rust and is totally bugfree, it will take a further 12-13 years before the bugprone C code goes down to 50%. [By then Rust may not longer be a hot language but that is for another thread (or async/await)] The point being, even if you add Rust, there is a long term need to "do better" in the C code. > maybe this is time to simply crate a new Open-Source OS from scratch = written in Rust? >=20 > manual rewrite of existing code seems too complex from a technical = standpoint. sometimes it's just easier to start from scratch? This would be about as quixotic as DARPA's TRACTOR program (TRanslate All C code TO Rust)! No such AI exists today. Any auto translated code needs to be hand checked. I suspect you're better off teaching the AI about the common code bugs in C and how to fix them or at least detect them. From nobody Thu Sep 5 20:36:09 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 4X0B3B6Dj2z5TsX7 for ; Thu, 05 Sep 2024 20:36:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0B3B3BTkz4pZ4 for ; Thu, 5 Sep 2024 20:36:22 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4fd19da17dfso636139e0c.1 for ; Thu, 05 Sep 2024 13:36:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725568581; x=1726173381; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lbDv8UvJsu6dETEKdr5P2bBqVAHtaWq3UjS71P0ORSA=; b=w8NaFp1pICvn6is5DdZPUG2Q9xZnQSGN2X3VSumkEmP5mS6U6LKmcK17efOFtmqL3Y oN8hIKT8SYljdkLuDj/sry1exBps8mVuqhAr/Yuj3+H4CgnEjKCJcz4IpuIoDK4aD1Wz pxYcNqMnwSZLgMO5Zp0D75S6WsQ+a6FGQSqPd7ImdgnvL/GwnJg+AuM3vk1r+akJKCzj +iOegU0zg4opZKximwWIh58zNC3hpbylxWVk905n5ImOPrfEyQvKX6+hTlqXtl/Iu5Ok 6O+IPxzFE8O7X3xPJQbmPK6Ky00ZH0KdaKnUpn6HpxG48mumX9yJ0yGbJC4UJde0PCTb HvZQ== X-Gm-Message-State: AOJu0YwCqw/Gbmg/wcNTJ6OrZrzzxBgz/L2J+xx2MabsXuo4/p5K4Z44 WwaYO2lyDsQQ8evWnDFSpa6h55wPGZK0cDZTxl5yDB7bAH29iF4Qcwg04caDfyogALyg9TppknW W4V8slXY/IGdL07wHrkkZwkfBKc6f5w== X-Google-Smtp-Source: AGHT+IEWLBO22iHCQNbu/8WKmrOG1E3rUzV+s3HqJhvSB1Uwj7y0z8SeBrPCKZBjjggNeBRJ32C+T42BmZkGpAQbOfo= X-Received: by 2002:a05:6122:168d:b0:4f5:d98:5ec3 with SMTP id 71dfb90a1353d-5019d4952e5mr655286e0c.6.1725568581410; Thu, 05 Sep 2024 13:36:21 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Thu, 5 Sep 2024 14:36:09 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X0B3B3BTkz4pZ4 On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh wrote: > > > > On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers = wrote: >> >> By now I expect that most of you have seen the long list of new >> security advisories that just came out. Strikingly, all were the >> result of memory handling errors. And none of them wouldn't have >> happened if their respective programs had been written in a >> memory-safe language. > > > FreeBSD represents hundreds of thousands or millions of man hours > in its current form (depending on how you measure it). It has evolved > over 30 years. To get to the same level of maturity in a rust rewrite wou= ld > take a similar amount of time. But even if it took an order of magnitude > less because rust is that much better, that represents a huge pool of > manpower that don't seem to be hanging out around the project just > waiting for something to do. Sure. I for one am not volunteering to rewrite CTL next week. > > Where do the resources for this come from? Without enough resources, > the rewrites will be crap and nobody will want to use them (or maybe even > FreeBSD). The rewrites to date have lost functionality (though maybe not > functionality that's important) relative to what they replace. Which rewrites are you thinking of? > > So great, we should switch to rust. But so far we have no way to do that > incrementally (other than a parallel build system, which isn't very FreeB= SDish). > And if we can't even find the resources to do that minimal level of work,= how > can the rest possibly be robustly undertaken? > > Warner Your point is obvious; FreeBSD is too big to rewrite the whole thing. But my point stands: new projects (whether inside of FreeBSD or not) should almost always be using a safe language. And any component that needs a major overhaul anyway should probably also be written in a safe language, too. From nobody Thu Sep 5 21:06:12 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 4X0BmV6Zs8z5TxHb for ; Thu, 05 Sep 2024 21:08:42 +0000 (UTC) (envelope-from dsl@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 4X0BmV65p0z4vQT; Thu, 5 Sep 2024 21:08:42 +0000 (UTC) (envelope-from dsl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725570522; 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=r9dn/8/RGwEdVZ1rszk3TVaSZNQyHg8Hqhnulq6NhQg=; b=iIMTmkVJffFPQJ7QJEFtHzmyohyD4m4BdEg0t8u77xXg/wJa5k1cTVYdkTclG5HnivIDQ/ SDgGZmAb6Qn4T9ZGUwSrlhMA6IObRR1gj7+lBrZDMS+xuN/WIU6o92UR4mZqp2Le069vvR kP3WzQm+t+sAF+9pqZEU/rfULdOu1LCVpHsC2sOFmhYWifkDH0421JV+ejG9tqIuoYafA3 kZh10KMaypIe6b03uQEbA7yr5D5+zIKcKwcypQDXl5UquvH4YU4X7YtF3ode1rFXvL3vKY 79ZI06A9BSMHG4Yoy9k6NGUIhI218MyoXpuC/Ao++A5oYFh0IJ0tyYMrH1LJcw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725570522; a=rsa-sha256; cv=none; b=Eecgky92xZVRNBq2CpAHJbV1c9cmpWh4p8sZvCib62dz06AMOYRe6fYzLbsjlMFB6MeDcf USOy2fhLS2rDVUalo74H9StdnZc2GT/qymD/8HM3et3ODy/jzQvW9TYOPnw7eOSlfr20pF ZZKqskWtIP/s5UPhcH01ZQN5ozgWg/lVYzbk21Yhiq4NXZF887/X/N7kzWBDb7pLf8JXhX yQEt0j/XkOmiqdCSVLaMd99w1O26fun66Pfki1KAgDAcGxR5A3+ULaTaoqmVL69TmkOCVZ ZngaAmuQL0ZzoEvxTxREb6bdNjQYBExyPT6upFzaMZj62FN8nJmXZUh/Cma7Fg== 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=1725570522; 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=r9dn/8/RGwEdVZ1rszk3TVaSZNQyHg8Hqhnulq6NhQg=; b=jbP5eEiqS5awACK4BNW1+Vz6e7NZoaP5W93fRme8sm+PfRJgeWbe9kXYtEFvV2SavxRWL5 RznmBj/8k7RIrwKeHqErGPMoj6n5g/YlrCklP7wC4nFgdPNWTLtWDrDLVlxBZP10Msa33h BD2D3XcBoJGVaIAvvfvLoDAFMNFeRZnUDbe7DNtcQ+UlxIn+e4yVpeJuwGmO+b+12kPGSl GgaBioHcNsrc3XUk/n/rX4yT7WWr7gHhAiPWckfA2IeQ3qPnS3VavTdlJKoHhd9QJIB7hY uoAN3SDzWVHNKAtTOt/HEu+Pz4J5EOsV9ETHhj8UPo8tU6Rb6fbIVyhtehU7jQ== Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dsl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0BmV3f3nz1J5Y; Thu, 5 Sep 2024 21:08:42 +0000 (UTC) (envelope-from dsl@FreeBSD.org) References: <7d1a0ae5-b047-4b2b-894e-615af0a5093e@digitaldaemon.com> User-agent: mu4e 1.8.13; emacs 29.4 From: Dmitry Salychev To: Jan Knepper Cc: Alan Somers , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Thu, 05 Sep 2024 23:06:12 +0200 In-reply-to: <7d1a0ae5-b047-4b2b-894e-615af0a5093e@digitaldaemon.com> Message-ID: <86y1453j1k.fsf@peasant.bootbsd.com> 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: text/plain Jan Knepper writes: > Is this used? > > Does anyone from the team monitor this? > > https://scan.coverity.com/projects/freebsd > I check it from time to time hoping to find anything about sys/dev/dpaa2, but no issues there reported. I wonder whether Coverity configured in a specific way not to get any code from CURRENT. > > > On 9/5/24 14:09, Alan Somers wrote: >> By now I expect that most of you have seen the long list of new >> security advisories that just came out. Strikingly, all were the >> result of memory handling errors. And none of them wouldn't have >> happened if their respective programs had been written in a >> memory-safe language. >> >> In fact, of all the C bug fixes that I've been involved with (as >> either author or reviewer) since May, about three quarters could've >> been avoided just by using a better language. >> >> The real takeaway here is that C is no longer sufficient for writing >> high quality code in the 2020s. Everyone needs to adapt their tools. >> Programmers who don't will increasingly come to resemble experimental >> archaeologists, i.e. people who learn flintknapping to "keep the >> knowledge alive". Such people are valuable, but definitely niche. I >> for one don't want my career to go in that trajectory. >> >> To summarize, here's the list of this week's security advisories, and >> also some other recent C bug fixes of my own involvement: >> >> Buffer overflow >> =============== >> https://cgit.freebsd.org/src/commit/?id=3aaaca1b51ad844ef9e9b3d945217ab3dd189bae >> CVE-2024-45288 FreeBSD-SA-24:09.libnv >> https://cgit.freebsd.org/src/commit/?id=a06fc21e770a482c8915411ebc98c870e42dd29b >> CVE-2024-41928 FreeBSD-SA-24:10.bhyve >> https://cgit.freebsd.org/src/commit/?id=af438acbfde3d25dbdc82b2b3d72380f0191e9d9 >> CVE-2024-42416 FreeBSD-SA-24:11.ctl >> https://cgit.freebsd.org/src/commit/?id=db87c98168b1605f067d283fa36a710369c3849d >> FreeBSD-SA-24:11.ctl >> https://cgit.freebsd.org/src/commit/?id=5c9308a4130858598c76f3ae6e3e3dfb41ccfe68 >> CVE-2024-32668 FreeBSD-SA-24:12.bhyve >> >> Integer overflow >> ================ >> https://cgit.freebsd.org/src/commit/?id=36fa90dbde0060aacb5677d0b113ee168e839071 >> CVE-2024-45287 FreeBSD-SA-24:09.libnv >> https://cgit.freebsd.org/src/commit/?id=c3e6dfe55c0e81d0717b0458bc95128384c3ebe8 >> FreeBSD-SA-24:14.umtx >> >> Use after free >> ============== >> https://cgit.freebsd.org/src/commit/?id=670b582db6cb827a8760df942ed8af0020a0b4d0 >> CVE-2024-45063 FreeBSD-SA-24:11.ctl >> https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 >> CVE-2024-43102 FreeBSD-SA-24:14.umtx >> >> Uninitialized memory access >> =========================== >> https://cgit.freebsd.org/src/commit/?id=ea44766b78d639d3a89afd5302ec6feffaade813 >> CVE-2024-8178 FreeBSD-SA-24:11.ctl >> https://cgit.freebsd.org/src/commit/?id=0f2b2276abc305905e7d88619a7abca26b0dd7eb >> >> Memory Leaks >> ============ >> https://cgit.freebsd.org/src/commit/?id=2909ddd17cb4d750852dc04128e584f93f8c5058 >> >> Incorrect union member access >> ============================= >> https://cgit.freebsd.org/src/commit/?id=9a5a7c90d5e5971fe2b9c9265e9279a6f173a8f3 >> CVE-2024-6119 FreeBSD-SA-24:13.openssl >> >> Concurrent unsychronized memory access >> ====================================== >> https://cgit.freebsd.org/src/commit/?id=1f5bf91a85e93afa17bc9c03fe7fade0852da046 >> >> RAII >> ==== >> https://cgit.freebsd.org/src/commit/?id=4b3141f5d5373989598f9447ab5a9f87e2d1c9fb >> >> Unchecked errors [^1] >> ====================== >> https://cgit.freebsd.org/src/commit/?id=35f4984343229545881a324a00cdbb3980d675ce >> https://cgit.freebsd.org/src/commit/?id=eced2e2f1e56b54753702da52a88fccbe73b3dcb >> https://cgit.freebsd.org/src/commit/?id=f625d038d2ae59fa1ae81b76079da464ed6db61a >> >> Not preventable by a safer programming language >> =============================================== >> https://cgit.freebsd.org/src/commit/?id=7d6932d20aedbbb220cd78e90ab4e82d1abaad31 >> https://cgit.freebsd.org/src/commit/?id=6efba04df3f8c77b9b12f1df3e5124a7249b82fc >> https://cgit.freebsd.org/src/commit/?id=4b72bab96e8978eaed30fd44f7f51e1b4918d4db >> https://cgit.freebsd.org/src/commit/?id=b64afa41d56e98b5817aaf14c7deb0fa7e2142fb >> >> [^1]: while not memory-safety bugs, Rust's lints actually make >> ignoring errors like this pretty difficult. So I consider these bugs >> to have been preventable. >> -- https://wiki.freebsd.org/DmitrySalychev From nobody Thu Sep 5 21:12:44 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 4X0BsQ2PPqz5Txxw for ; Thu, 05 Sep 2024 21:12:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0BsQ0nFBz3xpF; Thu, 5 Sep 2024 21:12:58 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-49bd7809c84so225454137.0; Thu, 05 Sep 2024 14:12:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725570777; x=1726175577; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PeIdGN3uM7emVL1SA+BglvgoEyGUBrFUAxteHQWaoF8=; b=wMpRXWYJZU3LANbCiBCGjFDw/Kaj7JAXR0zWbd9eUeJHDzY7fT3F78c/NlKXXN+kK2 /WmHSeSR239Jq8rl2Gc99jstOFNtiibgOI//m7Yy3QLLfL/BfCjQS0jQde2dWM/nFr6t whyi+nxVwMMLXgLQRV0QfyY3TYslLeZ3Qng1nPKC7xgPw/UsE1rrP66iTxGQf+1pU5kQ BsAZPOTu7KE2pA4TupAzMQiZnW2RrzCsCOOex+Wo9ODp785n7CiYXCskwlNmffhH79cu Qkil7qiuBUvSJ2MjDI9SWfDPmahj/K7p+6fpMcCK06PxVsuuPLN/35IMa7TF5iuA+OEn rqYw== X-Forwarded-Encrypted: i=1; AJvYcCXMpG+m1nzY9oeKviBQBDAqXRGmMvIlhbheV8bB3z6DbyPFuGPrbA6qOhIM1iMOkkZsWg3C72ZPp6iTxufbDPk=@freebsd.org X-Gm-Message-State: AOJu0YyY1eysD0H8ORH1cg4N9lL44vjc+YIa6EtLi4bE85Lw/sAshRDt yNibHelRVilxjcgt/2xleXxKHWK0NxO9+cumWC8j9cV+pgwLprgN5/Vnrm4eOHMp6e/h83aMxtR k2tb25E8APOcDSd1aGioz76cYNwdqQA== X-Google-Smtp-Source: AGHT+IFjCtdalzivHJ6qeKiK3hhPVZxdYtVL5oBDE4GUeh202awl/yiVumljbybZzluz3njX3cke6WceQo6LXPLFlPM= X-Received: by 2002:a05:6102:c8d:b0:49b:cb21:f33e with SMTP id ada2fe7eead31-49bde267b54mr663552137.19.1725570776885; Thu, 05 Sep 2024 14:12:56 -0700 (PDT) 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 References: <7d1a0ae5-b047-4b2b-894e-615af0a5093e@digitaldaemon.com> <86y1453j1k.fsf@peasant.bootbsd.com> In-Reply-To: <86y1453j1k.fsf@peasant.bootbsd.com> From: Alan Somers Date: Thu, 5 Sep 2024 15:12:44 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Dmitry Salychev Cc: Jan Knepper , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X0BsQ0nFBz3xpF On Thu, Sep 5, 2024 at 3:08=E2=80=AFPM Dmitry Salychev wr= ote: > > > Jan Knepper writes: > > > Is this used? > > > > Does anyone from the team monitor this? > > > > https://scan.coverity.com/projects/freebsd I used to check it, years ago. But I gave up. The UI is too hard to use and false alarms are both too frequent and too hard to suppress. Plus, it's a real drag that I can't run the tool myself. Instead, I need to wait for the next scheduled run. From nobody Thu Sep 5 21:07:00 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 4X0BtK3Fssz5Ty5k for ; Thu, 05 Sep 2024 21:13:45 +0000 (UTC) (envelope-from ske-89@pkmab.se) Received: from mail1.bemta32.messagelabs.com (mail1.bemta32.messagelabs.com [195.245.230.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.bemta32.messagelabs.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0BtJ46mTz40Lq for ; Thu, 5 Sep 2024 21:13:44 +0000 (UTC) (envelope-from ske-89@pkmab.se) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ske-89@pkmab.se designates 195.245.230.66 as permitted sender) smtp.mailfrom=ske-89@pkmab.se X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRWlGSWpSXmKPExsVyYCl7ky6r/K0 0g+2bZS22b/7H6MDoMePTfJYAxijWzLyk/IoE1oy5r7uZClq5Kk49uM3cwDiXo4uRi0NIYDqj xOnme4wQzgJGiZcT1rJ0MXJyCAvoSaza85m1i5GDQ0RAXmLBeXuQMIuArsS0/VfYQWwJAQWJL zvmsYLYnAK1EvOmHAez2QREJfZ132UGsXkFTCXevT7ACGILCchIXFp0DKo3WOJ+/3/GCYzcCx gZVjGaFqcWlaUW6ZrqJRVlpmeU5CZm5uglVukm6qWW6panFpfoGuollhfrpRYX6xVX5ibnpOj lpZZsYgR6PqWYrWYH4/o9jfqHGCU5mJREeVVu3EwT4kvKT6nMSCzOiC8qzUktPsQow8GhJMG7 UvZWmpBgUWp6akVaZg4wCGHSEhw8SiK8x3mB0rzFBYm5xZnpEKlTjIpS4rz7pIASAiCJjNI8u DZY4F9ilJUS5mVkYGAQ4ilILcrNLEGVf8UozsGoJMx7DmQ7T2ZeCdz0V0CLmYAWh5jfBFlcko iQkmpg0jDf7ZQREhD6e+k8pn2rlua2nonY9UOrvs5vu3n267dTnu3bz6S++5k6xxVpE4vpPR8 OzL/lzLda5ICKI79j8a//n6s1fld/vmt2LDrl9XKzrmj7P6ohX0+9k77z6IHcw/XVGrMKHlU7 Lfuzkm2izaWaawXbTzVbOQhqS3tp/z2wyzyv7ZJWvf/UVfGlNv0eChJPfe2XRLZ4H1ZaqzChr MjbvjBG9dJTrqAXBe/tld9qZZ/VOaS2LGDp4RUOO0rYfs0+zXF2RVnFIZ3FZevmacbXczvPM/ guZLRhP3P5nAmbnvNKWb/bqzBVd5bBU5WmUqvKV4bxH5Z3FFizsxzlWeYj+m4S243u7+/9Ojc 8UWIpzkg01GIuKk4EAPrnBjn3AgAA X-Env-Sender: ske-89@pkmab.se X-Msg-Ref: server-3.tower-564.messagelabs.com!1725570821!49652!1 X-Originating-IP: [192.165.7.130] X-SYMC-ESS-Client-Auth: outbound-route-from=fail X-StarScan-Received: X-StarScan-Version: 9.114.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23576 invoked from network); 5 Sep 2024 21:13:41 -0000 Received: from unknown (HELO PSY-APP020.precio.lan) (192.165.7.130) by server-3.tower-564.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 Sep 2024 21:13:41 -0000 Received: from berenice.precio.lan ([172.27.68.201]) by PSY-APP020.precio.lan with Microsoft SMTPSVC(10.0.17763.1697); Thu, 5 Sep 2024 23:13:40 +0200 Received: from pkmab.se by berenice.pkmab.se with uucp id aa18097 for ; Thu, 5 Sep 2024 23:13:40 +0200 (CETDST) Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org Date: Thu, 5 Sep 2024 23:07:00 +0200 (CETDST) X-Mailer: ELM [version 2.4 PL23] In-reply-to: from "Alan Somers" at Sep 5, 24 12:09:18 pm From: ske-89@pkmab.se Message-ID: <202409052313.aa18097@berenice.pkmab.se> X-OriginalArrivalTime: 05 Sep 2024 21:13:40.0799 (UTC) FILETIME=[7B5444F0:01DAFFD8] X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; NEURAL_HAM_SHORT(-0.71)[-0.708]; R_SPF_ALLOW(-0.20)[+ip4:195.245.230.0/23]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[pkmab.se]; RCVD_COUNT_THREE(0.00)[3]; FROM_NO_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16509, ipnet:195.245.230.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.245.230.66:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_TRACE(0.00)[0:+]; HAS_XOIP(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[195.245.230.66:from] X-Rspamd-Queue-Id: 4X0BtJ46mTz40Lq 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 Alan Somers wrote: > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. ... > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: After checking several of these examples, I'm wondering what the code would have looked like in some "better language", where those bugs would have been avoided? E.g for the "use after free" or "unitialized memory" examples. To me, several of those bugs seem fairly complex, and not just a question of having bounds checking for arrays or a borrow checker for pointers, or something simple like that. But maybe the bugs could have been detected and prevented if the code would have been forced to be expressed in a completely different manner by some other language? Or what is your vision of how that would be accomplished? You seem to be saying that certain examples would be solved by a better language, and certain ones would not, so I suppose you do have some vision of how that would work. I'm just curious to learn more, since it is not obvious to me, and thus all the more interresting. /Kristoffer Eriksson From nobody Thu Sep 5 21:58:41 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 4X0CtK4gmpz5V50y for ; Thu, 05 Sep 2024 21:58:49 +0000 (UTC) (envelope-from me@levitati.ng) Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0CtK1ZqZz46Yx for ; Thu, 5 Sep 2024 21:58:49 +0000 (UTC) (envelope-from me@levitati.ng) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: a=rsa-sha256; b=aDRLpJ5k+8de6jG9w7AO9zxCOPupgDTA0D3nry92dVsGs+Jj2RQsNKnxUKxmoVoEjhWXGLhcQtZfe4F9nRzD6t2Enx+OTTjKASMRPZx/PeL50WYE9nCZhtOG30guQQiVy1zbZ20Vl5k2mM8iuBlfRaPX767Rawf28P/6trfMbyg0TdadZDEF+mL4OP9N/CjNUVHV+qi9LEUCvn6ZZGf+Kx7eW8qS70JvvyBD6gHfIa/sMzLcYaHJdzpnxtPfeHjg+YIxE6JrYfmM81+CEgzVzUweGANt75CJZBysoA2YCz7xNSuJoUIp0pHkYwegfY1CsjG0DXtS8WMU0BxIF67xgA==; s=purelymail1; d=levitati.ng; v=1; bh=IMHmNJXCEaFt77HqPUR7hZBibwZWO2sw9hvIJbiFrT4=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=dbU8rCsxUIB8XZ+nXCvcIHf9UdR1hrySsca0mZRDly8fGZfylZz9ejRPxyzao2BcNvORwG6ci9TnDuIM2Ndl2D2tTuIBDBqwxDtGJAw5he2tWBNGARZIZi6ROuFKKd2uNh7XFf5aV3qo6suPqvcb9Ll3KpWb5FxOBhop+lmD5NMoKTDAc4Si9LChjTX6kvr1ymlQH8/3+0gTugskaQ1nwgu70sE0gW/GWKN3i1rqGAludFBJYOLCyUK+NZlGUw9N+VmKFgNvCOWSecLw6BOB31i2FrPB/SPN8u+YsrONDqk/gD/oLClsKlgZon7UYNRx0ZhRhHckCk8HgzVUANt4FQ==; s=purelymail1; d=purelymail.com; v=1; bh=IMHmNJXCEaFt77HqPUR7hZBibwZWO2sw9hvIJbiFrT4=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 25799:4744:null:purelymail X-Pm-Original-To: freebsd-hackers@freebsd.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPA id 1515553003; Thu, 05 Sep 2024 21:58:41 +0000 (UTC) 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 Date: Thu, 05 Sep 2024 23:58:41 +0200 From: "Rein Fernhout (Levitating)" To: Karl Denninger Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-Reply-To: References: User-Agent: Purely Mail via Roundcube/1.6.8 Message-ID: X-Sender: me@levitati.ng Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4X0CtK1ZqZz46Yx On 2024-09-05 21:20, Karl Denninger wrote: > On 9/5/2024 14:09, Alan Somers wrote: > >> By now I expect that most of you have seen the long list of new >> security advisories that just came out. Strikingly, all were the >> result of memory handling errors. And none of them wouldn't have >> happened if their respective programs had been written in a >> memory-safe language. >> > > To argue that the answer is to put a diaper on a child so it does not > drop excrement on the carpet is to forever treat said human as an > infant without control of its sphincters. While such an answer might > be necessary for a short period of time in all young human creatures > it also should be obvious that we are all walking around today without > them and thus said prophylaxis is to cover for a deficiency rather > than a necessity. > This argument has been had since Rust was first created. Rust was created to be a solution to a real problem that cannot be solved by "just writing better C code". Rust was created because projects like Chromium found that 70% of their bugs are memory related.[0] The amount of time wasted discovering, debugging and fixing these bugs is unreal. These bugs and vulnerabilities are inevitable if you use a language like C no matter the skill of your developers. I also wanted to speak to the "C is a dying language" argument. I am a third-year CS bachelor student at one of the best technical universities in the Netherlands. Our bachelor never did cover much C, but after the last year even the low level OS course has been ported to Rust code. Our memory management and concurrency courses now also offer Rust examples and exercises. That means that our CS students are now primarily taught Python, Java, Rust and Assembly. Students are expected to somewhat be able to read C code but are never asked to write any. Of the students that I know that actually program in their free time, all of them do so in Rust. I don't even know a single student who can even write C. We take about 400 new students each year. I love C but writing it is cumbersome and doing it correctly even more so. There's a major learning curve which few new programmers are even starting on. Contributing to a C codebase is also much more cumbersome. They each have their own rules, own standards and conventions and their own build system. With Rust you know what to expect. And as for the speed of Rust, there *can* be some overhead by the runtime. But Rust has so much fewer footguns that you will inevitably write more performant code. If you use the standard libraries reallocating vectors, hashmaps etc you will be using the fastest algorithm known and possibly using SIMD or other architecture specific instructions. It's developers like me who will have to maintain codebases like FreeBSD in 10 or 20 years and I've personally written magnitudes more Rust than C. For me there's no point in starting a project in C other than giving myself a challenge. Is it possible for FreeBSD to incrementally start accepting Rust code? I would think so. I recently spoke with zirias on the forums about the potential of a dedicated "authentication service" which would allow unprivileged processes to verify user authentication without ever needing to read the password store (as an alternative to pam_unix(8)). In my opinion a daemon like this would be a prime candidate for writing in Rust. The major downside of this is that I expect few FreeBSD developers currently know Rust. But I think it will be much easier to find new Rust contributors than C contributors and this will even more so in the future. Rust is absolutely thriving in FOSS right now. And to the developers who don't know Rust: It shouldn't take long for an experienced C developer to learn the basics. There is already an abundance of Rust literature including the Rust book[1]. And you can play with Rust in the playground[2]. [0]: https://www.chromium.org/Home/chromium-security/memory-safety/ [1]: https://doc.rust-lang.org/stable/book/ [2]: https://play.rust-lang.org From nobody Thu Sep 5 22:37:27 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 4X0Dl86Q3gz5V9md for ; Thu, 05 Sep 2024 22:37:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0Dl84kGJz4DLv for ; Thu, 5 Sep 2024 22:37:40 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-49bd3bf3b4cso429598137.3 for ; Thu, 05 Sep 2024 15:37:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725575860; x=1726180660; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QgWmZ2wcG3svf7DvwM1EAJv0CaUPt1ZxAk3zPWU7/4g=; b=c3cvFgJCiT1TXvaTAaVJEgK+9+qCN0sPcuH7d32JuyXny4l4sw12gdS/U48KPM+nTK SBFXdV2LyHCjk0S7CeOPo1mbn7A6YjH9lcGvnfadTvf177FPloieSaCtq0earVRbqr+J AxbR0R+/34xs3nWOs5fwMD4H0/zoa4pBXRlv2w8ZA3qgv2XoYcsFogFQFTLALCKUrt24 YPxKcwBiFp1FW07mVjNrOSlzd406/hvD4cK/6/C05cGjn5sH0uD/SW8FW8q2ENo1g2Br /ob9lu6rvH6lPkq5cQnd+1tHq02Yfs7vUL/sPuJ3EsjtF4AEp8zkF3prJ5I/OIfGkZFS fgLg== X-Gm-Message-State: AOJu0YxcjjQ/J+ig9gVTXCVUTZBewit8lJOTRwqeWxSrs0V5TvDa2R94 w+GW8TyjHTMX2RzicrZFfXtQmuPONsmjifA5fNitzfTI8AaejRXsPgB91E3uXSP5abZrUmRdlRh ujuoiLVXE9dRqAFKlHa1Nm3MdZsw= X-Google-Smtp-Source: AGHT+IF2cUktS3jXFDtEFLMPzx/QlwV69moBZyaqAlm6B9OxSUph8idJ15GgZ3i4XL9duHHkEYiatUdDx7ufJy4H8g4= X-Received: by 2002:a05:6102:50a0:b0:497:6a9b:36bd with SMTP id ada2fe7eead31-49a5af816a6mr30929409137.29.1725575859515; Thu, 05 Sep 2024 15:37:39 -0700 (PDT) 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 References: <202409052313.aa18097@berenice.pkmab.se> In-Reply-To: <202409052313.aa18097@berenice.pkmab.se> From: Alan Somers Date: Thu, 5 Sep 2024 16:37:27 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: ske-89@pkmab.se Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X0Dl84kGJz4DLv On Thu, Sep 5, 2024 at 3:13=E2=80=AFPM wrote: > > Alan Somers wrote: > > In fact, of all the C bug fixes that I've been involved with (as > > either author or reviewer) since May, about three quarters could've > > been avoided just by using a better language. > ... > > To summarize, here's the list of this week's security advisories, and > > also some other recent C bug fixes of my own involvement: > > After checking several of these examples, I'm wondering what the code > would have looked like in some "better language", where those bugs would > have been avoided? > > E.g for the "use after free" or "unitialized memory" examples. > > To me, several of those bugs seem fairly complex, and not just a > question of having bounds checking for arrays or a borrow checker > for pointers, or something simple like that. > > But maybe the bugs could have been detected and prevented if the > code would have been forced to be expressed in a completely > different manner by some other language? Or what is your vision > of how that would be accomplished? > > You seem to be saying that certain examples would be solved by > a better language, and certain ones would not, so I suppose you > do have some vision of how that would work. > > I'm just curious to learn more, since it is not obvious to me, > and thus all the more interresting. > > /Kristoffer Eriksson Excellent question. Here's why a selected sample of those bugs would've been prevented had the programs been written in Rust. 2909ddd17cb4d750852dc04128e584f93f8c5058 Rust uses RAII wherever possible. Variables are automatically deallocated = when they leave scope. Circular references are almost impossible to create due = to the lifetime borrow checker. So bugs like this really just can't happen in idiomatic Rust code. CVE-2024-45063 Written in idiomatic Rust, the lun->write_buffer would've had a type like Option>>. The only way to free that would be to remove the contents of the Option, leaving None in its place. So a subsequent use-after-free would be impossible. The bug would still be present, but instead of a use-after-free the READ BUFFER command would have to create an= d zero-initialize a new buffer. The bug would be immediately obvious to the = user since READ BUFFER would return the wrong data (all zeroes). CVE-2024-8178 Rust abhors uninitialized data. LLVM doesn't even guarantee that a program will run correctly when accessing it. So written in idiomatic Rust, lun->write_buffer would either be zero initialized, or it would be allocate= d like `Vec::with_capacity(262144)`. In the latter case, it would be partial= ly initialized during the WRITE BUFFER command. But given the semantics of SC= SI's READ BUFFER and WRITE BUFFER commands, I think zero-initialization is more appropriate. CVE-2024-6119 In Rust, initializing a union via one member and then accessing it via anot= her is actually considered to be the same thing as reading uninitialized memory= , and LLVM abhors it. The idiomatic solution is to use a enum (which is simi= lar to a Java enum) instead of a union. The enum is basically a tagged union, = so the programs knows at runtime which member is initialized. That makes bugs like CVE-2024-6119 impossible in idiomatic Rust code. CVE-2024-41928 This bug involved zero-initialing a structure, but with the wrong size. Idiomatic Rust code never uses anything like bzero. In fact, zero-initiali= zing a structure is considered unsafe, because an all-zero pattern isn't valid f= or all structures. To initialize a structure in Rust, you either need to prov= ide the value of every member or else use an initializer function. The simples= t intializer is often STRUCT_NAME::default(), which can be automatically deri= ved and is often equivalent to bzero. But all of those methods know the size o= f the structure, so bugs like this aren't possible in idiomatic Rust code. CVE-2024-45287 In debug builds of Rust, integer math operations are by default bounds-chec= ked at runtime. That catches many bugs like this. For release builds, integer math operations are wrapping by default, but the programmer can also select bounds-checking. In this particular case, however, a Rust programmer would= n't have attempted to multiply those two integers together. Instead, `value` would've been a Vec of some type, and it would be initialized like `Vec::with_capacity(nvp->nvp_nitems)`. 1f5bf91a85e93afa17bc9c03fe7fade0852da046 Rust's borrow checker will ensure that a single variable cannot be modified from two locations at the same time, or modified in one and read from anoth= er. This check happens at compile-time, with 0 runtime cost. For cases whether= the compiler cannot determine whether the access is safe, various runtime optio= ns are available, like Mutex. In this case, the function's author actually performed a cast to remove "const" from the variable. Rust makes such cast= s harder, and it's better type system makes them far less necessary. 35f4984343229545881a324a00cdbb3980d675ce and eced2e2f1e56b54753702da52a88fccbe73b3dcb In idiomatic Rust, a falliable function returns a `Result` type, and the compiler is smart enough to know when a programmer ignores the Result. It = will generate a warning, and most projects are configured to treat that type of warning as an error. So bugs like this don't usually happen. They can, however. A programmer can deliberately ignore the error, as in eced2e2f1e5= , or he can "unwrap" it. That means "panic on error", which is not terribly different from the bug fixed by 35f49843432. So it's possible but far from certain that a Rust implementation would've prevented these bugs. That's w= hy in my summary I said "about three quarters" could've been avoided. From nobody Thu Sep 5 22:51:29 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 4X0F3H0yXyz5VCh3 for ; Thu, 05 Sep 2024 22:51:39 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0F3G5Xf2z4HNw for ; Thu, 5 Sep 2024 22:51:38 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725576691; x=1726243357; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=oJKXOeRKHSaBdfXa5f+bqGp5QyI7Ft4j6nW3e8VuksI=; b=ZNcy3Nymv9meJSjJwwFXR0WCaZ7Jw7xiSTnzIc0gK8gRK/c7XccyCleoqVxXDZ/xy+ltXEV5 ttsvxDMLTbEnRNTyD44Vte7lNTG1u5wdz5PaXB9XeA16s1f+EOkL7ocyOXMQ933+8v73l0+2B0 nEsGZhg3Z/X1kw3ZNuGkokeOFz9GotiiBQbF9YsSHx2hECn0rWrmIWC6ep6qG+ZCQ8vlvtr2Pw 90kGIxB2A2amGhUAE62Czg5B1nbcazmRi9daVlB2+2+raF1j6B2rRKwcbpdcfvfY7MjYA4rsOw X60c9f76j07Wrr+8sRgfpGktquDOZs1D82bWX0A34o3gKl8A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725576691; x=1726243357; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=oJKXOeRKHSaBdfXa5f+bqGp5QyI7Ft4j6nW3e8VuksI=; b=7v2fMzo9UKhd5LHrPdb8NQXPaW05Ac8nu/BE52Bd4Ru/Mft7KojHQBPpkbUfUXchipxmueLE GzUa0u2QvMz+Dg== Date: Fri, 06 Sep 2024 00:51:29 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: ske-89@pkmab.se Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240905225129.UvYYMXDa@steffen%sdaoden.eu> In-Reply-To: <202409052313.aa18097@berenice.pkmab.se> References: <202409052313.aa18097@berenice.pkmab.se> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X0F3G5Xf2z4HNw 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 sigh. now i am back. ske-89@pkmab.se wrote in <202409052313.aa18097@berenice.pkmab.se>: |Alan Somers wrote: |> In fact, of all the C bug fixes that I've been involved with (as |> either author or reviewer) since May, about three quarters could've |> been avoided just by using a better language. |... |> To summarize, here's the list of this week's security advisories, and |> also some other recent C bug fixes of my own involvement: | |After checking several of these examples, I'm wondering what the code |would have looked like in some "better language", where those bugs would |have been avoided? Examples. I find the absolute opposite after checking four. Ie, if you implement some SCSI command - - /* - * struct scsi_sense_data, which is currently set to 256 bytes, is - * larger than the largest allowed value for the length field in the - * REQUEST SENSE CDB, which is 252 bytes as of SPC-4. - */ - ctsio->kern_data_len = cdb->length; - ctsio->kern_total_len = cdb->length; + ctsio->kern_data_len = ctsio->kern_total_len = + MIN(cdb->length, sizeof(*sense_ptr)); This is a super clear logic error, that even says the comment, which did not care for security related impacts. It came in as part of a tremendious super large patch "Add the CAM Target Layer (CTL)." (130f4520cba830cc6da47c9f871fed78710a4709) in 2012, 34000 lines of code additions. There were a couple of fixup commits. It seems to have been sponsored, but i have no idea of review or anything. Compared to the WireGuard stuff, for example. Now i had to look more deeply why the commit says three bytes whereas the naive eye counts four. (Maybe NUL terminated.) The ones from OpenSSL and ctld are more complex. But the libnv is pretty clear again, it even uses strnlen() (urgh). |E.g for the "use after free" or "unitialized memory" examples. Examples. You are just saying. |To me, several of those bugs seem fairly complex, and not just a |question of having bounds checking for arrays or a borrow checker |for pointers, or something simple like that. Two of four. |But maybe the bugs could have been detected[.] yes, maybe. I doubt it. |[.] and prevented if the |code would have been forced to be expressed in a completely |different manner by some other language? Or what is your vision |of how that would be accomplished? Actually yes. String objects. I mean it is easy to say that, but if you look at the SCSI thing, one would normally do things like eg we_parse_THIS_SCSI_COMMAND([.]u8 *buf, u16 len){ ... /* C99 */{ struct a_mmc_cmd_x42_resp_data_head *dhp; ^argument etc of THIS_SCSI_COMMAND dhp = R(struct a_mmc_cmd_x42_resp_data_head*,buf); buf += sizeof(*dhp); len -= sizeof(*dhp); } ... irp = R(struct a_mmc_cmd_x42_isrc_resp*,buf); Unfortunately it was forgotten for one of many use cases, where a byte buffer of reality matches a structure of a language abstraction. How could a different language aid here. |You seem to be saying that certain examples would be solved by |a better language, and certain ones would not, so I suppose you |do have some vision of how that would work. And *i* am saying that for example the nvlist could have been done very safely in C, if instead of strnlen() etc something more sane would have been used. Like a string object. But it is more typing work etc. *That* of course, yes. |I'm just curious to learn more, since it is not obvious to me, |and thus all the more interresting. This is all very unspecific. I have also seen quite a lot of things. What should be the answer to this unspecific question, except continuation of this thread? |/Kristoffer Eriksson --End of <202409052313.aa18097@berenice.pkmab.se> In support for that swedish hm virgin, yes, sweden is not a clean country for sure. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Sep 5 22:51:53 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 4X0F3h3xDmz5VCT9 for ; Thu, 05 Sep 2024 22:52:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0F3g2WVQz4J7L; Thu, 5 Sep 2024 22:51:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=mrVKZH6b; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::831 as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-456757d8871so8818291cf.0; Thu, 05 Sep 2024 15:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725576718; x=1726181518; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=iezm2oDnk2EshbwXp6MXvP+p92UYNWcl2ZVPJzJxCSM=; b=mrVKZH6bL8WeYt+6411We3Pr/p3MRUT3QuARxmSWhUf8JKmnViT6wwQ1PVLpdPCGF+ TPu7EK93h2aVqWZlS8zLL74UoMb3n18b626ZRE3ig87ZhRtzxR/8qIjXHkj2dDTGwzuq 2VjRd6WIsf8Pv+lyehmPNNJOUjJd64Zx0QqJsycpkJG/B1bRNuzcaqvLf2FMAcJRq3uE aylXUqw3J/Fs8A1P1z0OlG4FgCbaVl1TEKKHF9PtccxiCtptVLs1oNtZqtDL5mrjdgli r3FuwnDqPmG74bbcGfgZHzakdQ+bVaRM4Mw/qINr1BJxxaK5xMFj9a1PAN1lBlBXaudR rxTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725576718; x=1726181518; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iezm2oDnk2EshbwXp6MXvP+p92UYNWcl2ZVPJzJxCSM=; b=fuSnFRvljBgVuF7tv/t8caZC48+/1aeoIV5P21RD6b4QxkIYqHxrwoNUEqPX/WxW4V 51r2V2HCL+f6ksJ6hbX+jZjtD8tM7ku34dUBXku5fcI7O841MQJ8gyGBT+Pvx+840jhB gIoqlPYH14PPdIH2/4+W7j1izWuzkHujsl20o9TFnwo6hXBJejQGOlH4MCYG1OckmQw/ q5/KMP4xx0yvVjAS8kF17eFE3guRzgm/gRu7DyotQhOODDC960YXXH++/o6h3MAeQ4bJ rnMQdhE1tAYivVgdCoo1PrbbUFg8zrGzIVxlLgoYGC38sOoihZP/O3aXNAF0buuGME03 FU0w== X-Forwarded-Encrypted: i=1; AJvYcCU190HvQ0OMuaifMhCV5Iqsxf9Emztcltcwxt5D76kEK+t5IBoltNCwnpNf5iX9caH5dEeQ@freebsd.org, AJvYcCVPo+gc2zxqV286XClyjqzUk4cmwoWz0/XQvfdCqpxDd+ouXmstgbu0NGVYiAqYRahkGPWM@freebsd.org X-Gm-Message-State: AOJu0Yyl2YrOniOuSZOnfs09uuacl+GNoZv0Zx34j/gg8qrDzvkelF6R PCzl5M3FNDLUq6+qsyvmWcaSrXssEPDDR76/svLcQWU9t8HwYukXLIZChw== X-Google-Smtp-Source: AGHT+IGAKClnPjn6A3uTEPtr+rL+T7gqPURXhB/EaPVuNZO0ZaZOeBFGzZ+67QKty02MB4lR0Lj7Qg== X-Received: by 2002:a05:622a:13d3:b0:43f:edde:7a55 with SMTP id d75a77b69052e-4580c6e1f22mr8189351cf.28.1725576717232; Thu, 05 Sep 2024 15:51:57 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45801cbb1acsm11233491cf.71.2024.09.05.15.51.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2024 15:51:56 -0700 (PDT) Date: Thu, 5 Sep 2024 18:51:53 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: kevans@freebsd.org, imp@freebsd.org, bapt@freebsd.org Subject: adding new flua libraries Message-ID: 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: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.57 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4X0F3g2WVQz4J7L FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's intended for use by the base system, and so far has a few consumers, but not many so far. (As an aside, flua's intended scope is not totally clear to me. Is it only for use by the base system? What compatibility guarantees does it provide, if any?) A few flua modules wrapping FreeBSD libraries (e.g., libjail) are available, but they don't provide enough to make flua useful as a general purpose programming tool. It lacks interfaces for interacting with the system (e.g., libc/libsys/libutil/etc wrappers) as well as standard programming facilities (e.g., classes, higher-order functions, etc.). Here I'm mostly interested in discussing the former. I think flua could be a very useful alternative to shell scripts and C code where performance is not critical. It's very good at wrapping C interfaces and thus could be used to make FreeBSD features (jails, bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who don't want to interact with C. It's a lot of work to build up a set of flua modules that provide enough functionality to be generally useful. My feeling is that the easiest way to get there is to wrap C interfaces directly (to the extent that that's possible, but it's usually easy) and expose them in flua as a stable interface. Libraries written in pure Lua (or other languages that interoperate well with Lua) could be built on top of that. I'm inclined to start by wrapping libc and libsys interfaces in a manner similar to luaposix. There, the namespace is partitioned by C headers, so posix.unistd contains identifiers from unistd.h, posix.sys.stat contains identifiers from sys/stat.h, and so on. In fact, flua already has a small subset of luaposix's functionality. Wrapping C interfaces isn't much fun, but it's easy, and it saves us having to come up with names and interfaces (naming things is hard), and helps ensure that the glue code is relatively small and doesn't impose a large testing burden. Moreover, C interfaces don't change much and are subject to well-understood compatibility constraints, which should mean that Lua interfaces built on top of them are subject to the same constraints. Assuming there's general agreement on that approach, the question I'd really like to answer is, what should the namespace look like? It would be useful to provide a posix module compatible with luaposix, but that obviously won't contain FreeBSD-specific functionality. I propose having a top-level "freebsd" namespace for all modules implemented in the base system, excluding posix and contrib libraries which already define a Lua interface (libucl is the one example I see so far; we could import sqlite bindings as well). Then, if we follow luaposix's convention, we could have freebsd.sys.capsicum.* for Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent wrappers, and so on. The posix module could simply provide a subset of freebsd.*. Maybe it's better to separate C wrappers from native Lua modules though, so it could be better to have freebsd.c.sys.capsicum.*, etc., and provide higher-level interfaces for FreeBSD features under freebsd.pf, freebsd.zfs, freebsd.jail, etc.. I'm not really sure. In the interest of prompting discussion a bit, I posted some patches to add some example wrappers to flua: https://reviews.freebsd.org/D46553 https://reviews.freebsd.org/D46554 https://reviews.freebsd.org/D46556 Does anyone have opinions on anything I've brought up above? I'm pretty happy to write a lot of this glue code or find ways to automate it, as I've already done a fair bit of it, but it's hard to make progress without having some rigourous conventions for the flua namespace (again, naming things is hard). From nobody Thu Sep 5 23:03:01 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 4X0FJS5Dykz5VDrS for ; Thu, 05 Sep 2024 23:03:04 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0FJS1BrXz4MBD for ; Thu, 5 Sep 2024 23:03:04 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sdaoden.eu header.s=citron header.b=a6shKal1; dkim=pass header.d=sdaoden.eu header.s=orange header.b=iZYqkEPl; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725577383; x=1726244049; h=date:author:from:to:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=m8EMiA/Am2sqcAo84z2jsHRbAjrn2lQOia2j7fVSYUw=; b=a6shKal1UqiozMRdo5SQNsVAvktW2A3uDcvXOukFAwsIYbiyO9FDp9HV1NDYV3tlpUae9Bk9 pwW7GBvR+2Hhl0dUgxa/eH8jIqg8Ylq6Bm1CtzGf1+zEmn+4TCAwsTm1pXveJohW4cS/uZU7cN CRPj3ZqSgbcDCZZzS0Ff2UopFk3zUqgxtttWxvXc+VlEUhMZKEBuxl5FeXhViDjRLWV4y1Nc26 VwdLyVOvmUAsxZS/mpLP97VS6ikUcbOh75XXS9At+jis/mttIsObzrPaOEhNVH0Qx/crqyAEyI 1cQPVoFKIXziFQgZCvmC1X1k4RWKTEV1RHI0/XHdqfbr+ePQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725577383; x=1726244049; h=date:author:from:to:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=m8EMiA/Am2sqcAo84z2jsHRbAjrn2lQOia2j7fVSYUw=; b=iZYqkEPlOKJdVMQd47pQrHAFSHa3DlShAhSuAE6iFCiHoaBDh4dffWp3dzsyXiywzjW3XBST +61wAZzEb9jDBQ== Date: Fri, 06 Sep 2024 01:03:01 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240905230301.XxRHheIX@steffen%sdaoden.eu> In-Reply-To: <20240905225129.UvYYMXDa@steffen%sdaoden.eu> References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.875]; R_DKIM_ALLOW(-0.20)[sdaoden.eu:s=citron,sdaoden.eu:s=orange]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[sdaoden.eu]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[sdaoden.eu:+] X-Rspamd-Queue-Id: 4X0FJS1BrXz4MBD 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 Steffen Nurpmeso wrote in <20240905225129.UvYYMXDa@steffen%sdaoden.eu>: ... hihihi saw the Somers .. but wanted to add |Ie, if you implement some SCSI command .. | we_parse_THIS_SCSI_COMMAND([.]u8 *buf, u16 len){ |... | /* C99 */{ | struct a_mmc_cmd_x42_resp_data_head *dhp; | |^argument etc of THIS_SCSI_COMMAND | | dhp = R(struct a_mmc_cmd_x42_resp_data_head*,buf); | buf += sizeof(*dhp); | len -= sizeof(*dhp); |} |... | irp = R(struct a_mmc_cmd_x42_isrc_resp*,buf); This thing tested the lengths accordingly, of course. ... |very safely in C, if instead of strnlen() etc something more sane |would have been used. Like a string object. But it is more |typing work etc. *That* of course, yes. Now Option>> or Vec::with_capacity(262144) is not that much shorter than doing something in C proper types at hand provided. (Btw C object constructors usually initialize their types, too, .. that is why they are called constructors. Of course: you need these objects, stdlib has none, but FILE, which is horrific. Vec, hmhm...) ..etcetcetc. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Sep 5 23:11:47 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 4X0FVX4nFqz5VFyd for ; Thu, 05 Sep 2024 23:11:48 +0000 (UTC) (envelope-from kevans@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 4X0FVX4LkRz4Nbs; Thu, 5 Sep 2024 23:11:48 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725577908; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wpYHRSdhkJePMCYlwNheBDUmemIjnsyWLX1VwLl6v2c=; b=gJG689h66HAvKXNqB9do1ISmJA1Gbmo6cCmSmW2GO2Jb29SbKjycgFl3cytn9ja4GIkAn1 oCsI1RiRMptBxD5Gs6TDRLGPWfB8FoZxaTQvafpSA1wiGLJWdWFmyNWiBhGZR1IPV0D4Wj P3JF91omAx5RjibFHKY+yetZEhmf/ibwgcbiqd/Ie3ydPDN5NXomAMivv4NgULesgiWabb q8NcNGyVxpMBJ3UFreep4EY7uUN9NyIqVZJsPM/9DHdRQvT/kR7S/i1PCQnm8w+oQeCklx gGOHazCN1xbMnuWY75JEtPraWqiJUL7SCqILeZ/FUEimq9IWfvcu102Ofs+CGg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725577908; a=rsa-sha256; cv=none; b=PU798w9B0HaaDQEV6LE+/knU0kVM49jbmBfFuHs1H0Tde2I5bIdE7HstOZWTFGD+BRI5gk yis110FWG2IJdGMtffuw+TGID4S5Q7i0MiOQphx1nDiEmEFIC/hqUfRZldrnXJordEshLz bBn2GWv/k363Tf1eH7OZf5DXMEsHITQ8T/1lhcF79kcqdhveEbuz2w5bOlJNxkZLGL6Vq1 BoRw7SUw8UczA2yw4gzJq6kp5y7CbMChAdc0YadZK2QstrDjYmGuRNeONhFECD8cbQzosa y/B9bDzI21ymLGnkuD9ZaD6f759vC4F5kRQYN3Dbs74U+YazmUPKIzzp7xEwUw== 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=1725577908; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wpYHRSdhkJePMCYlwNheBDUmemIjnsyWLX1VwLl6v2c=; b=f4Gc4++6fVNg7N9yNeFdEcex1mOZKMgFlplqdPe6L75M2HDBfwsSx854NZ9Kzb76b0P4ff hx+1oOjJ1jabUfqv9kVnFOFv+liiKDHuzX948Pw7yymE02u2y1BVEPc+pP19tOLe800y0O BM1QAB45jrY9GCuAmcJHrIHxu/ewzfE1d+LfOkfsdAmQqKuVpJFbDh4FPm6yY/Dsequvoh 3WhVFKTFrV+nWBPLsdw8AfmmxbYFH44spqt01ZGhNf2QYtzbvd0cY9sc6Rfs5zblfzYQCy yfBWyulno1LDUK8mIjA3sGuRznGkh7C92oob1JkTifTjUKr+Akbp9ixokox2Vw== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0FVX19Ymz1M2p; Thu, 5 Sep 2024 23:11:48 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Thu, 5 Sep 2024 18:11:47 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: adding new flua libraries To: Mark Johnston , freebsd-hackers@freebsd.org Cc: imp@freebsd.org, bapt@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/5/24 17:51, Mark Johnston wrote: > FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's > intended for use by the base system, and so far has a few consumers, but > not many so far. (As an aside, flua's intended scope is not totally > clear to me. Is it only for use by the base system? What compatibility > guarantees does it provide, if any?) > Only by the base system (hence the rename and hiding it in /usr/libexec), no guarantees except for modules we've re-implemented subsets of- if a conflicting name exists in ports, its use must be compatible with that. > A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > available, but they don't provide enough to make flua useful as a > general purpose programming tool. It lacks interfaces for interacting > with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > standard programming facilities (e.g., classes, higher-order functions, > etc.). Here I'm mostly interested in discussing the former. > > I think flua could be a very useful alternative to shell scripts and C > code where performance is not critical. It's very good at wrapping C > interfaces and thus could be used to make FreeBSD features (jails, > bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > don't want to interact with C. > > It's a lot of work to build up a set of flua modules that provide enough > functionality to be generally useful. My feeling is that the easiest > way to get there is to wrap C interfaces directly (to the extent that > that's possible, but it's usually easy) and expose them in flua as a > stable interface. Libraries written in pure Lua (or other languages > that interoperate well with Lua) could be built on top of that. > > I'm inclined to start by wrapping libc and libsys interfaces in a manner > similar to luaposix. There, the namespace is partitioned by C headers, > so posix.unistd contains identifiers from unistd.h, posix.sys.stat > contains identifiers from sys/stat.h, and so on. In fact, flua already > has a small subset of luaposix's functionality. Wrapping C interfaces > isn't much fun, but it's easy, and it saves us having to come up with > names and interfaces (naming things is hard), and helps ensure that the > glue code is relatively small and doesn't impose a large testing burden. > Moreover, C interfaces don't change much and are subject to > well-understood compatibility constraints, which should mean that Lua > interfaces built on top of them are subject to the same constraints. > > Assuming there's general agreement on that approach, the question I'd > really like to answer is, what should the namespace look like? It would > be useful to provide a posix module compatible with luaposix, but that > obviously won't contain FreeBSD-specific functionality. > > I propose having a top-level "freebsd" namespace for all modules > implemented in the base system, excluding posix and contrib libraries > which already define a Lua interface (libucl is the one example I see so > far; we could import sqlite bindings as well). Then, if we follow > luaposix's convention, we could have freebsd.sys.capsicum.* for > Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent > wrappers, and so on. The posix module could simply provide a subset of > freebsd.*. > I think that's fine. Ideally, we probably just import luaposix wholesale now once we get the bootstrap flua module situation sorted and we can just re-export those implementations into the freebsd.* namespace similar to how we discussed luaposix was doing things today, unless those interfaces are weird (I don't remember them being problematic, though). > Maybe it's better to separate C wrappers from native Lua modules though, > so it could be better to have freebsd.c.sys.capsicum.*, etc., and > provide higher-level interfaces for FreeBSD features under freebsd.pf, > freebsd.zfs, freebsd.jail, etc.. I'm not really sure. > > In the interest of prompting discussion a bit, I posted some patches to > add some example wrappers to flua: > https://reviews.freebsd.org/D46553 > https://reviews.freebsd.org/D46554 > https://reviews.freebsd.org/D46556 > Will take a look when I get a bit of time. > Does anyone have opinions on anything I've brought up above? I'm pretty > happy to write a lot of this glue code or find ways to automate it, as > I've already done a fair bit of it, but it's hard to make progress > without having some rigourous conventions for the flua namespace (again, > naming things is hard). > We should also figure out where to document this stuff (policy, mostly- we have a 3lua section for libraries themselves). Thanks, Kyle Evans From nobody Thu Sep 5 23:47:35 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 4X0GJ04jB8z5VM4f for ; Thu, 05 Sep 2024 23:47:44 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from kachina.jetcafe.org (kachina.jetcafe.org [216.86.209.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "jetcafe.org", Issuer "E5" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0GJ00xDPz4S8F; Thu, 5 Sep 2024 23:47:43 +0000 (UTC) (envelope-from dave@jetcafe.org) Authentication-Results: mx1.freebsd.org; none X-Envelope-To: freebsd-hackers@freebsd.org X-Rcpt-Mailer: X-Mail-Mailer: local X-SMTP-Proto: ESMTP Received: from bigus.dream-tech.com (bigus.jetcafe.org [216.86.209.7]) by jetcafe.org (8.18.1/8.18.1) with ESMTP id 485Nlalh094747; Thu, 5 Sep 2024 16:47:36 -0700 (PDT) (envelope-from dave@jetcafe.org) Date: Thu, 5 Sep 2024 16:47:35 -0700 From: Dave Hayes To: Alan Somers Cc: FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: <20240905164735.21881914@bigus.dream-tech.com> In-Reply-To: References: 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12028, ipnet:216.86.192.0/19, country:US] X-Rspamd-Queue-Id: 4X0GJ00xDPz4S8F On Thu, 5 Sep 2024 12:09:18 -0600, Alan Somers wrote: >By now I expect that most of you have seen the long list of new >security advisories that just came out. Strikingly, all were the >result of memory handling errors. And none of them wouldn't have >happened if their respective programs had been written in a >memory-safe language. So I was going to respond more to this, but my auto-inserted signature does a better job than I would have. :) -- Dave Hayes - Computer and Internet Consultant - LA CA, USA >> *Opinions expressed above are entirely my own* << A king who feared wasps once decreed that they would be abolished. As it happened, they did him no harm. But he was eventually stung to death by scorpions. From nobody Fri Sep 6 00:34:29 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 4X0HL21R27z5VT7w for ; Fri, 06 Sep 2024 00:34:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0HL1685Kz4YBx; Fri, 6 Sep 2024 00:34:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-457e2537611so9249661cf.0; Thu, 05 Sep 2024 17:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725582872; x=1726187672; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=J+GhkTNtw/JKf+6xwo1l+a+rtYG9mHPjTFLMG2baIr8=; b=MCJJFLQ4ytrbZrvrK1RN8m+4Nxv3A/HM0LOM5XKNt+qM6o2EK4RigIhnTC04fUqsPk RSgsZ43uhsLqt/SbZ/XHbDaIfoN+zG+SmeENTN95aYP58AO/sJuYYduOLC/5mU1BlzLu Yl5XDlIu6FWI3lUz5vVQqmQKSP79+hnq2yaP0qkZcFaQTXrvAnuyeKcmNQbeSX0v35W0 okVaSI/b6hOpspZtbTImSV06qqiRFlcyLMWu3FRgvqgdnDia/4OQ6cIjHkKuesKykU6A T3wVTUnBUvI3dW9Mdm0plHCOYsIFOd1MfR4E9mTlXAPAreE+DkwyaV4yPM2KL60thheH FWoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725582872; x=1726187672; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J+GhkTNtw/JKf+6xwo1l+a+rtYG9mHPjTFLMG2baIr8=; b=V3Fx+SYdaJ3n71q9uuMKpAfJC+/YfymdGvBW/JvdPjkQr7pJ96xmrlcVFvM09hiLhE cSevN1KS9hhFoyikomj/vQWLo4NF6lBppw1svHc6/fFMQHiVbDQR8u1CE0pqhJDSDHCW DRNta7oaVBFFPqozyqYm05jWc6vpBQc/iqPM8Fm2lE9CsBzqi3bZBsQ1Br3rU8VbVXU7 CfwkNVi4NZbVyL30pDvLsBpE+AAVTBPcCxIQTMCtPznnQND57QGgUYNA5IcdDcciIxgm GgcEq+zKRRm1Ij3kiK4maIqPtuuwVUR3PBb3NcIlzif7zi3fi+vYFEdL0kDj9r4mP96P Nh4Q== X-Forwarded-Encrypted: i=1; AJvYcCU6ZU45R1escKPcyAdchsDiM4pGYvokmtr6MUWiAzPolUdiBpO/TVi0tjjfG2vH3o/uFKhM@freebsd.org, AJvYcCV+1ab10V8VJU4U3Srt7VnKltxYAbBBWp8ijKLDkE5t+eJpEzr0yBw9NHVNZQIzW/Vey0SK@freebsd.org X-Gm-Message-State: AOJu0YwLK7DBRdHz4xbN7EZ4slDEgirOwyIWLKoCZ9plNiB4zYSrDVYW NHK+IrhXwW8tjO5ahk1dOSABunlo/t6m6h7/xTtP7PS3zd5aoKPBeSEV/A== X-Google-Smtp-Source: AGHT+IGjVs0jhhQ7zF1HFRmIVmy8QT7NpmN6E2yXI7uZyfuCzVltUG4qBRndKfx8W8OmjeODTGAmHg== X-Received: by 2002:a05:6214:4a82:b0:6c3:55f3:ed92 with SMTP id 6a1803df08f44-6c5282fc762mr14029956d6.2.1725582872343; Thu, 05 Sep 2024 17:34:32 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6c520317329sm12162776d6.84.2024.09.05.17.34.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2024 17:34:31 -0700 (PDT) Date: Thu, 5 Sep 2024 20:34:29 -0400 From: Mark Johnston To: Kyle Evans Cc: freebsd-hackers@freebsd.org, imp@freebsd.org, bapt@freebsd.org Subject: Re: adding new flua libraries Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0HL1685Kz4YBx On Thu, Sep 05, 2024 at 06:11:47PM -0500, Kyle Evans wrote: > On 9/5/24 17:51, Mark Johnston wrote: > > FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's > > intended for use by the base system, and so far has a few consumers, but > > not many so far. (As an aside, flua's intended scope is not totally > > clear to me. Is it only for use by the base system? What compatibility > > guarantees does it provide, if any?) > > > > Only by the base system (hence the rename and hiding it in /usr/libexec), no > guarantees except for modules we've re-implemented subsets of- if a > conflicting name exists in ports, its use must be compatible with that. > > > A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > > available, but they don't provide enough to make flua useful as a > > general purpose programming tool. It lacks interfaces for interacting > > with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > > standard programming facilities (e.g., classes, higher-order functions, > > etc.). Here I'm mostly interested in discussing the former. > > > > I think flua could be a very useful alternative to shell scripts and C > > code where performance is not critical. It's very good at wrapping C > > interfaces and thus could be used to make FreeBSD features (jails, > > bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > > don't want to interact with C. > > > > It's a lot of work to build up a set of flua modules that provide enough > > functionality to be generally useful. My feeling is that the easiest > > way to get there is to wrap C interfaces directly (to the extent that > > that's possible, but it's usually easy) and expose them in flua as a > > stable interface. Libraries written in pure Lua (or other languages > > that interoperate well with Lua) could be built on top of that. > > > > I'm inclined to start by wrapping libc and libsys interfaces in a manner > > similar to luaposix. There, the namespace is partitioned by C headers, > > so posix.unistd contains identifiers from unistd.h, posix.sys.stat > > contains identifiers from sys/stat.h, and so on. In fact, flua already > > has a small subset of luaposix's functionality. Wrapping C interfaces > > isn't much fun, but it's easy, and it saves us having to come up with > > names and interfaces (naming things is hard), and helps ensure that the > > glue code is relatively small and doesn't impose a large testing burden. > > Moreover, C interfaces don't change much and are subject to > > well-understood compatibility constraints, which should mean that Lua > > interfaces built on top of them are subject to the same constraints. > > > > Assuming there's general agreement on that approach, the question I'd > > really like to answer is, what should the namespace look like? It would > > be useful to provide a posix module compatible with luaposix, but that > > obviously won't contain FreeBSD-specific functionality. > > > > I propose having a top-level "freebsd" namespace for all modules > > implemented in the base system, excluding posix and contrib libraries > > which already define a Lua interface (libucl is the one example I see so > > far; we could import sqlite bindings as well). Then, if we follow > > luaposix's convention, we could have freebsd.sys.capsicum.* for > > Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent > > wrappers, and so on. The posix module could simply provide a subset of > > freebsd.*. > > > > I think that's fine. Ideally, we probably just import luaposix wholesale > now once we get the bootstrap flua module situation sorted and we can just > re-export those implementations into the freebsd.* namespace similar to how > we discussed luaposix was doing things today, unless those interfaces are > weird (I don't remember them being problematic, though). Could you please elaborate on the bootstrap module problem? Regarding importing luaposix, one potential problem there is with interopability of userdata types, mainly the treatment of file descriptors (which I would want to use in, e.g., freebsd.sys.capsicum). For example, in the reviews linked below I went with a userdata type for file descriptors so that they can be garbage-collected automatically, but luaposix doesn't do that AFAICS. To me that's a bit unsavoury but I'm not sure how important it really is. I do think that we could quite quickly and easily reimplement most of luaposix, for what it's worth. > > Maybe it's better to separate C wrappers from native Lua modules though, > > so it could be better to have freebsd.c.sys.capsicum.*, etc., and > > provide higher-level interfaces for FreeBSD features under freebsd.pf, > > freebsd.zfs, freebsd.jail, etc.. I'm not really sure. > > > > In the interest of prompting discussion a bit, I posted some patches to > > add some example wrappers to flua: > > https://reviews.freebsd.org/D46553 > > https://reviews.freebsd.org/D46554 > > https://reviews.freebsd.org/D46556 > > > > Will take a look when I get a bit of time. Thank you kindly. > > Does anyone have opinions on anything I've brought up above? I'm pretty > > happy to write a lot of this glue code or find ways to automate it, as > > I've already done a fair bit of it, but it's hard to make progress > > without having some rigourous conventions for the flua namespace (again, > > naming things is hard). > > > > We should also figure out where to document this stuff (policy, mostly- we > have a 3lua section for libraries themselves). Yep, I added a hacky posix.3lua in one of the reviews linked above. A man page for flua itself is probably the next step. From nobody Fri Sep 6 01:00:07 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 4X0HvY4RJ1z5VXKB for ; Fri, 06 Sep 2024 01:00:09 +0000 (UTC) (envelope-from me@levitati.ng) Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0HvX3jzjz4bnY for ; Fri, 6 Sep 2024 01:00:08 +0000 (UTC) (envelope-from me@levitati.ng) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=levitati.ng header.s=purelymail1 header.b=jSIFdBAS; dkim=pass header.d=purelymail.com header.s=purelymail1 header.b=pEWzOymh; dmarc=pass (policy=reject) header.from=levitati.ng; spf=pass (mx1.freebsd.org: domain of me@levitati.ng designates 34.202.193.197 as permitted sender) smtp.mailfrom=me@levitati.ng DKIM-Signature: a=rsa-sha256; b=jSIFdBASSp+3Pjhtkf/jvEGttvL7pFBkYVXlwmPU9v5o9a/V+zzzTigUkDbY/9WBkYjpKx+a/frM1b6/eMvsfY5S60uBJh/1Acqlk3umZrAdnwhCMVOES2L4SEUhdCtktTwCMgWI+D5F4clRk3SlQkUvmjchNRvBcgq3w05SJAKwkfZfy9ma8iPVGcQE2nuV+ZrV/Yiu3NjNtWQRoPCQ9RO4KPYe+2+GaVegw7kAXbs6Z8Ha3TB3t0b15E+zSKTPUChdKfXyykVKcEL10kYmQD12JoCrcD+l+h80iN9PAvgy+Oo58e95lcMiaGtvD/+1rA217swYGYXQ8ydBVV+pPQ==; s=purelymail1; d=levitati.ng; v=1; bh=6K+URWWVGDVJIyMHPixKmM14DtusiZbU1vRvZ7okAPo=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=pEWzOymhuu7PpMjZm3ebvuz6pLRQQtxYu7KCgW7pLfS/mNR+jE91ElmcN4ijUkSoqt3ErnVnoA2bjFl+0bjc37dSoFfllkLfPH29xkMva/mzH8wFeD0/uiugcYiBe5JDMQK9YmqwvW1uc7R9hK+tX/X9G32TvU1TId7pcybppIeUzyqdsb75SeT9VQMBBj1O7iTsL3ALGnSor9rSWBtq3FvAH2MFXiyRaDbEwLnHYBijnwbgmgPqPzrE+MQDoo3Nn0KfNIANjbQ7SMjirEN1Gvck9pqYTROy3fF5SvZuZFHpaUYQQk2ePjbgegIHFNVv66JpcPsFFoJ/ILiRMPgjSw==; s=purelymail1; d=purelymail.com; v=1; bh=6K+URWWVGDVJIyMHPixKmM14DtusiZbU1vRvZ7okAPo=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 25799:4744:null:purelymail X-Pm-Original-To: freebsd-hackers@freebsd.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPA id 1861793624 for ; Fri, 06 Sep 2024 01:00:07 +0000 (UTC) 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 Date: Fri, 06 Sep 2024 03:00:07 +0200 From: "Rein Fernhout (Levitating)" To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-Reply-To: References: <202409052313.aa18097@berenice.pkmab.se> User-Agent: Purely Mail via Roundcube/1.6.8 Message-ID: X-Sender: me@levitati.ng Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[levitati.ng,reject]; R_DKIM_ALLOW(-0.20)[levitati.ng:s=purelymail1,purelymail.com:s=purelymail1]; R_SPF_ALLOW(-0.20)[+ip4:34.202.193.197]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[me]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[levitati.ng:+,purelymail.com:+] X-Rspamd-Queue-Id: 4X0HvX3jzjz4bnY I wanted to quickly drop a link to this HN thread: https://news.ycombinator.com/item?id=41458508 The article covers how Rust is employed for bare-metal firmware in Android. I thought it might be an interesting read for those following this thread. If you have problems accessing the blogpost you can use this archive link: https://archive.is/HitH8 From nobody Fri Sep 6 01:34:20 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 4X0JgF31JFz5V7tH for ; Fri, 06 Sep 2024 01:34:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0JgF18YTz4j0j for ; Fri, 6 Sep 2024 01:34:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2d8881850d9so1242734a91.3 for ; Thu, 05 Sep 2024 18:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725586472; x=1726191272; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J9OfQhS+Vy4Lbl6ZQrNifTm5C4dBTbpCfygv1oYy3uA=; b=djRjGPZ2ywyin0IKKQQJLbDueB0YM5YzoJf+IHJUuCGDkxanr0iERiQGgsAc3a7MUa LfSyJEysAGcF/bzuTqovdDxCb2S1ZziPYb+Oatc3xl8NcQ6vyrDpneKnJj9zRmoMzxdZ 3+ZGHeeyUcM6Lc2FBoor4yAPgrqSC5mMTdfIziilu9mubiGy86G5TjeyZ9KV8wL91FMi fCitu7vcFn0x+t+c+JDRrY9ZA7Ygld8AcVTEJySEWHPMK1eVQHX5sN5GIzisaN0okRF/ pQFbqodaIsFgYDJJTuaouzI1BVO0YdTGcWCZ+Kwts7MIYXZGV/Z7iEM5ohYjSf3xodTc O6OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725586472; x=1726191272; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J9OfQhS+Vy4Lbl6ZQrNifTm5C4dBTbpCfygv1oYy3uA=; b=aSb6Pofe9UnYGpw0K1pC24QSL7hzHolJ9RBO6uT9Io6wGHBDe4PMPVLZWkhqLBfhBN 2TGFKamvHVLQd/PwmiGiJc9jA0sidC+d17KTjizeTotgl1UHqV6OsyHnCKaHlNXtxn6Y UVvqd5f0M161OTeS6OR82c+aAAc9b+9FCuvZUChFVRko598ycjUOCUNnkfp21Y61ZLXr 5nvvl2Br84aymEFSkyUrUSJCKLtGhsP7en6KvBVtfxpwIgU1/z3UG1YEV7EXG+DQON90 NpARSqN1bA+ZITpG3lFEJ6QfS//dpPD1/u0h/qAOxUMnK/FRF1fTYX6D4UWle5FiVn1b TDsQ== X-Forwarded-Encrypted: i=1; AJvYcCWjqTmcIyK9BuOm3ri2kH8vUYsiaKRVn/ITr1X/xXPD2qR1IImnRZdzowuRc+QaaNhIUetBRFi51w/rX1brZ+k=@freebsd.org X-Gm-Message-State: AOJu0YzV777Q1Dko75rHH7KKayaP7jEcxCHztQWxQ1DIhJ9tYweLl0GU LFoI0NcoZWbBUWxvGPwcju75hm/k6/gXkWP4Rsec5I4A5anFyKyNs7O4yfVoz7pqXclcdhaJtwI bKBjIk9GjKayZIqVvhFuILgGBr60kuiev9eVzaQ== X-Google-Smtp-Source: AGHT+IGjYSYjvonfozLQhznHNK6xcGOULmJF0BMUfXiAnLctT2RWKSrfdbYEoHgkqb7RfkKhUXTS//Ul9erB43n0hn8= X-Received: by 2002:a17:90a:a60d:b0:2d1:bf4b:4a6d with SMTP id 98e67ed59e1d1-2dad4def822mr1503642a91.1.1725586471837; Thu, 05 Sep 2024 18:34:31 -0700 (PDT) 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 References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> In-Reply-To: <20240905225129.UvYYMXDa@steffen%sdaoden.eu> From: Warner Losh Date: Thu, 5 Sep 2024 19:34:20 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Steffen Nurpmeso Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000af067f0621696844" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0JgF18YTz4j0j --000000000000af067f0621696844 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024 at 4:51=E2=80=AFPM Steffen Nurpmeso wrote: > sigh. now i am back. > > ske-89@pkmab.se wrote in > <202409052313.aa18097@berenice.pkmab.se>: > |Alan Somers wrote: > |> In fact, of all the C bug fixes that I've been involved with (as > |> either author or reviewer) since May, about three quarters could've > |> been avoided just by using a better language. > |... > |> To summarize, here's the list of this week's security advisories, and > |> also some other recent C bug fixes of my own involvement: > | > |After checking several of these examples, I'm wondering what the code > |would have looked like in some "better language", where those bugs woul= d > |have been avoided? > > Examples. I find the absolute opposite after checking four. > Ie, if you implement some SCSI command > > - > - /* > - * struct scsi_sense_data, which is currently set to 256 bytes, i= s > - * larger than the largest allowed value for the length field in > the > - * REQUEST SENSE CDB, which is 252 bytes as of SPC-4. > - */ > - ctsio->kern_data_len =3D cdb->length; > - ctsio->kern_total_len =3D cdb->length; > + =3D ctsio->kern_total_len =3D > + MIN(cdb->length, sizeof(*sense_ptr)); > > This is a super clear logic error, that even says the comment, > which did not care for security related impacts. It came in as > part of a tremendious super large patch "Add the CAM Target Layer > (CTL)." (130f4520cba830cc6da47c9f871fed78710a4709) in 2012, 34000 > lines of code additions. There were a couple of fixup commits. > It seems to have been sponsored, but i have no idea of review or > anything. Compared to the WireGuard stuff, for example. > Now i had to look more deeply why the commit says three bytes > whereas the naive eye counts four. (Maybe NUL terminated.) > So context is king here. It isn't at all clear to me this is a bug. 252 is the maximum for SPC-4, true. However, this code generates the sense code (a sense buffer is created by a device and sent to the host, and CTL implements a SCSI device). cdb->length is the length the caller has already allocated. You don't want the kernel to write more than that many bytes into the sense buffer, nor do you want it copying more than what's allocated into the kernel to send to the device (I'm not exaclty sure where this called from, or if it's all in the kernel copying it around). Capping it at 256 likely is unnecessary, but acts as a good sanity value. But since you give current line numbers, functions or files, I can't check to see if that's the case or not. The vast majority of sense buffers are like 4 to 20 bytes, and are often described by a simple C structure. I've not looked at the target mode size of CAM much (CTL), but I have written a lot on the host side. But without the rest of the code, it's hard to say if your obvious code is a mistake on your part, or not. And the comparison to wireguard is baseless speculation that you should not engage in without more knowledge of the situation. Its rude and unprofessional, and not at all conducive to a meaningful dialog. While the commit itself was rather large, it was for an already completed work that could not have been easily broken up into smaller bits, which is clear from the commit message. The commit message also states clearly that CTL was written at/by Copan for it's weird kinda sorta FreeBSD product (that part isn't in the commit message, but I know from talking to Justin, Scott and Ken) and then ported to stock FreeBSD by Spectra Logic. Ken Merry did this work, and also the port (with outers, if I recall correctly, though not in the commit message). Ken has several hundred commits to the FreeBSD SCSI stack (CAM). It had been in production for 7 years prior to its being included upstreamed to FreeBSD. This is quite different than the wireguard situation, even on its face. Ken (and Spectra Logic in general) has a very good reputation for being conservative in what they commit and for testing extensively (often in shipping product for years, as was the case here). So to throw around insults like you did is completely uncalled for. While I have more context (I've worked with Ken on and off for 20-odd years), that's not needed to understand this. And it's a violation of at least the spirit of the Code of Conduct we have. There's plenty to find in bad C code, but this example is a bad example for you to cite. It's not at all clear to me this is a bug (though without the full context I can't go check to see if there's something we need to fix, or it's just a misunderstanding). And you certainly don't need to toss in gratuitous insults to make your point: if the code is bad, your point is made without them. Warner --000000000000af067f0621696844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 5, 2024 at 4:51=E2=80=AFP= M Steffen Nurpmeso <steffen@sdaode= n.eu> wrote:
sigh.=C2=A0 now i am back.

ske-89@pkmab.se wr= ote in
=C2=A0<202409052313.aa18097@berenice.pkmab.se>:
=C2=A0|Alan Somers <asomers@freebsd.org> wrote:
=C2=A0|> In fact, of all the C bug fixes that I've been involved wit= h (as
=C2=A0|> either author or reviewer) since May, about three quarters coul= d've
=C2=A0|> been avoided just by using a better language.
=C2=A0|...
=C2=A0|> To summarize, here's the list of this week's security a= dvisories, and
=C2=A0|> also some other recent C bug fixes of my own involvement:
=C2=A0|
=C2=A0|After checking several of these examples, I'm wondering what the= code
=C2=A0|would have looked like in some "better language", where th= ose bugs would
=C2=A0|have been avoided?

Examples.=C2=A0 I find the absolute opposite after checking four.
Ie, if you implement some SCSI command

=C2=A0 -
=C2=A0 -=C2=A0 =C2=A0 =C2=A0/*
=C2=A0 -=C2=A0 =C2=A0 =C2=A0 * struct scsi_sense_data, which is currently s= et to 256 bytes, is
=C2=A0 -=C2=A0 =C2=A0 =C2=A0 * larger than the largest allowed value for th= e length field in the
=C2=A0 -=C2=A0 =C2=A0 =C2=A0 * REQUEST SENSE CDB, which is 252 bytes as of = SPC-4.
=C2=A0 -=C2=A0 =C2=A0 =C2=A0 */
=C2=A0 -=C2=A0 =C2=A0 =C2=A0ctsio->kern_data_len =3D cdb->length;
=C2=A0 -=C2=A0 =C2=A0 =C2=A0ctsio->kern_total_len =3D cdb->length; =C2=A0 +=C2=A0 =C2=A0 =C2=A0=3D ctsio->kern_total_len =3D
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MIN(cdb->length, sizeof(*sense= _ptr));

This is a super clear logic error, that even says the comment,
which did not care for security related impacts.=C2=A0 It came in as
part of a tremendious super large patch "Add the CAM Target Layer
(CTL)." (130f4520cba830cc6da47c9f871fed78710a4709) in 2012, 34000
lines of code additions.=C2=A0 There were a couple of fixup commits.
It seems to have been sponsored, but i have no idea of review or
anything.=C2=A0 Compared to the WireGuard stuff, for example.
Now i had to look more deeply why the commit says three bytes
whereas the naive eye counts four.=C2=A0 (Maybe NUL terminated.)

So context is king here. It isn't at all clea= r to me this is a bug.
252 is the maximum for SPC-4, true. Howeve= r, this code
generates the sense code (a sense buffer is created = by a device
and sent to the host, and CTL implements a SCSI devic= e). cdb->length
is the length the caller has already allocated= . You don't want the kernel to write
more than that many byte= s into the sense buffer, nor do you want it copying
more than wha= t's allocated into the kernel to send to the device (I'm not exaclt= y
sure where this called from, or if it's all in the kernel c= opying it around). Capping it at 256
likely is unnecessary, but a= cts as a good sanity value. But since you
give current line numbe= rs, functions or files, I can't check to see
if that's th= e case or not. The vast majority of sense buffers are like
4 to 2= 0 bytes, and are often described by a simple C structure. I've not
looked at the target mode size of CAM much (CTL), but I have written = a
lot on the host side.

But without the = rest of the code, it's hard to say if your obvious code
is a = mistake on your part, or not. And the comparison to wireguard is
= baseless speculation that you should not engage in without more knowledge
of the situation. Its rude and unprofessional, and not at all cond= ucive to
a meaningful dialog. While the commit itself was rather = large, it was for
an already completed work that could not have b= een easily broken up
into smaller bits, which is clear from the c= ommit message.

The commit message also states clea= rly that CTL was written at/by Copan
for it's weird kinda sor= ta FreeBSD product (that part isn't in the commit message,
bu= t I know from talking to Justin, Scott and Ken) and then ported to stock
FreeBSD by Spectra Logic. Ken Merry did this work, and also the por= t (with outers,
if I recall correctly, though not in the commit m= essage). Ken has several hundred
commits to the FreeBSD SCSI stac= k (CAM). It had been in production for 7 years
prior to its being= included upstreamed to FreeBSD. This is quite different than the
wireguard situation, even on its face. Ken (and Spectra Logic in general) = has a very
good reputation for being conservative in what they co= mmit and for testing
extensively (often in shipping product for y= ears, as was the case here).

So to throw around in= sults like you did is completely uncalled for. While I have
more = context (I've worked with Ken on and off for 20-odd years), that's = not
needed to understand this. And it's a violation of at lea= st the spirit of the Code
of Conduct we have.

There's plenty to find in bad C code, but this example is a bad e= xample
for you to cite. It's not at all clear to me this is a= bug (though without the full
context I can't go check to see= if there's something we need to fix, or it's just
a misu= nderstanding). And you certainly don't need to toss in gratuitous insul= ts
to make your point: if the code is bad, your point is made wit= hout them.

Warner
--000000000000af067f0621696844-- From nobody Fri Sep 6 01:39:24 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 4X0Jn60jgbz5V8Cr for ; Fri, 06 Sep 2024 01:39:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0Jn53rWVz4k8n for ; Fri, 6 Sep 2024 01:39:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-7cd8d2731d1so1174704a12.3 for ; Thu, 05 Sep 2024 18:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725586776; x=1726191576; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d6I7ICS1PCa1I8hi10EErwig3Nw+YMOEXqbdRgcHswg=; b=Ie2/wfCrRebHrQFU6NvZWwv2KqNNNd5/G1D/jlbe3w7qkm041+AmZhrJi88fKk5pnM jUQfmfuMlnv+mQ9pbqZpDM2xzMIbSYXDmhEBPLmwzCSn47FXvsEdb7JYAFCltbYECgW8 7Y/DxgLVlOr02zv6fdK0Np3n0Bp7oE74+qWL5nw7dXPBwrktTdbmxiJEE0u0JbgQCF9l YNYNftyu7Uk9bAQG34ustrEDrA5RMSdawaOsSkJImbmRSM/k6VMD1M0oEPbNHk2b2tDa FOo+opBcelQDq3ZII0tftQKWXma7zrRiTG//h6HsG5QNO/9PqHKFniNo62LGZB0mzPXR PXgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725586776; x=1726191576; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d6I7ICS1PCa1I8hi10EErwig3Nw+YMOEXqbdRgcHswg=; b=qp1DLenYmrSVmYdm4Pu3g35ItrcEfJFSmAegWOQaGi5DBO0+YAS2JqJUukAuRJsBgD RKClza0jEXpRmGpsb6fFGMYPvHab0gxT2qQJuVQ4aT6cYamvGQ8C8bnT8qNG4qY7yTUn qaYe5E5iQLrcXWlbwQnQhNr6nq9F4cYbpTYFUaQsc9cquzLoSL/p7sJtWEeb07B9rOCL FCwqMEKVVpuIz74WsC/OBirbRo/yZxiH1hVOw38SuI/7U2lEIxCtUG0+sLUYynK/K9YC pzGMERBek/XAhqvxfQ4aA2DTEHtQqKNgPODkLreIjvBjvJHzlN9dc1N5/49sewJAv15n KBGw== X-Gm-Message-State: AOJu0YxPgT8b+DPQOEJtwihh1fj0mE5gTqxAYGYOcIAy6hm50+aXOYLz jsR+ozjUobLLHeMr0nBW+k/zbJYoJNRAfg9NiywuUc8PpSetLIHg/qmVuts0yxCO4WnhzNzvrYo H5SJtM3Vfsbd2kLLatKyhLK230KfpQNgxXDlCOQ== X-Google-Smtp-Source: AGHT+IGL04Y0Q5CraytQhxb6hJU87DVt6olfkE/blgNbDlFS64pJT9E0qxQYNsDUs6jsKmRlpTbcCakAJffYx8eGLGk= X-Received: by 2002:a17:90a:f48b:b0:2c1:9892:8fb with SMTP id 98e67ed59e1d1-2dad4de4c5bmr1447959a91.5.1725586775757; Thu, 05 Sep 2024 18:39:35 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Thu, 5 Sep 2024 19:39:24 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000cc79a20621697aac" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0Jn53rWVz4k8n --000000000000cc79a20621697aac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024 at 2:36=E2=80=AFPM Alan Somers wr= ote: > On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh wrote= : > > > > > > > > On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers wrote: > >> > >> By now I expect that most of you have seen the long list of new > >> security advisories that just came out. Strikingly, all were the > >> result of memory handling errors. And none of them wouldn't have > >> happened if their respective programs had been written in a > >> memory-safe language. > > > > > > FreeBSD represents hundreds of thousands or millions of man hours > > in its current form (depending on how you measure it). It has evolved > > over 30 years. To get to the same level of maturity in a rust rewrite > would > > take a similar amount of time. But even if it took an order of magnitud= e > > less because rust is that much better, that represents a huge pool of > > manpower that don't seem to be hanging out around the project just > > waiting for something to do. > > Sure. I for one am not volunteering to rewrite CTL next week. > > > > > Where do the resources for this come from? Without enough resources, > > the rewrites will be crap and nobody will want to use them (or maybe ev= en > > FreeBSD). The rewrites to date have lost functionality (though maybe no= t > > functionality that's important) relative to what they replace. > > Which rewrites are you thinking of? > rs-gstat differs in a number of ways from gstat, including writing ANSI codes directly (at least in the version I looked at) rather than using curses. It's a little thing, and it might not really matter. > > > > So great, we should switch to rust. But so far we have no way to do tha= t > > incrementally (other than a parallel build system, which isn't very > FreeBSDish). > > And if we can't even find the resources to do that minimal level of > work, how > > can the rest possibly be robustly undertaken? > > > > Warner > > Your point is obvious; FreeBSD is too big to rewrite the whole thing. > But my point stands: new projects (whether inside of FreeBSD or not) > should almost always be using a safe language. And any component that > needs a major overhaul anyway should probably also be written in a > safe language, too. > I tend to agree with that. New, large products should be written in the mos= t appropriate language for their problem domain. We'll have a lot of legacy C code for a long time, though... I'm not entirely convinced it has to be a safe language, however, but that's more about practical considerations than whether it would be better... Warner --000000000000cc79a20621697aac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 5, 2024 at 2:36=E2=80=AFP= M Alan Somers <asomers@freebsd.or= g> wrote:
On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers <asomers@freebsd.org> wrot= e:
>>
>> By now I expect that most of you have seen the long list of new >> security advisories that just came out.=C2=A0 Strikingly, all were= the
>> result of memory handling errors.=C2=A0 And none of them wouldn= 9;t have
>> happened if their respective programs had been written in a
>> memory-safe language.
>
>
> FreeBSD represents hundreds of thousands or millions of man hours
> in its current form (depending on how you measure it). It has evolved<= br> > over 30 years. To get to the same level of maturity in a rust rewrite = would
> take a similar amount of time. But even if it took an order of magnitu= de
> less because rust is that much better, that represents a huge pool of<= br> > manpower that don't seem to be hanging out around the project just=
> waiting for something to do.

Sure.=C2=A0 I for one am not volunteering to rewrite CTL next week.

>
> Where do the resources for this come from? Without enough resources, > the rewrites will be crap and nobody will want to use them (or maybe e= ven
> FreeBSD). The rewrites to date have lost functionality (though maybe n= ot
> functionality that's important) relative to what they replace.

Which rewrites are you thinking of?

rs-= gstat differs in a number of ways from gstat, including writing ANSI codes<= /div>
directly (at least in the version I looked at) rather than using = curses. It's a little
thing, and it might not really matter.<= /div>
=C2=A0
>
> So great, we should switch to rust. But so far we have no way to do th= at
> incrementally (other than a parallel build system, which isn't ver= y FreeBSDish).
> And if we can't even find the resources to do that minimal level o= f work, how
> can the rest possibly be robustly undertaken?
>
> Warner

Your point is obvious; FreeBSD is too big to rewrite the whole thing.
But my point stands: new projects (whether inside of FreeBSD or not)
should almost always be using a safe language.=C2=A0 And any component that=
needs a major overhaul anyway should probably also be written in a
safe language, too.

I tend to agree wit= h that. New, large products should be written in the most
appropr= iate language for their problem domain. We'll have a lot of legacy C
code for a long time, though... I'm not entirely convinced it h= as to be a safe
language, however, but that's more about prac= tical considerations than
whether it would be better...

Warner
--000000000000cc79a20621697aac-- From nobody Fri Sep 6 02:39:39 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 4X0L6Q0Rhcz5VHlr for ; Fri, 06 Sep 2024 02:39:42 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0L6P6mtZz4tXl; Fri, 6 Sep 2024 02:39:41 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725590382; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lK60KEPIBxjhMR99m85xT7EZBhRDcl16JlZnRyzg4LU=; b=juZYHTzQeDmP4oIjEHmDzJzRyaEJzUbSn4uUV1e3ZYxx+hmzzjkJkOnoXGGmVfZ7ATw0Bh dG6k5xObRB8SUslaEeZjRnMvdwRwCPtSaOxcSO2wyP92E6qKv+uMCACV37dJ++5TEpNjB5 5/Grw3uJz1PZYviA5tODTg1y2g6iWkfIA5kacDH1EeBHKfyiLPtoQnnco6IPYJ0XDDL8OH e6eFB0nNT+r9CEXPIz453BGDv8lPYgGIHl29U6yEPzOyNBbRumSF+T0oop66zbfi8vyPGu 1zfno5qwRbjGGzbDP8u9uhZlOArNpHMZQWkDgzDotE9n8CM7zUvtI4ic99+H3w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725590382; a=rsa-sha256; cv=none; b=T4sK2sTpzb1YyzpdKZKUIJWyiIezbS1hp5ZUrrl+GFkhi0XX9OCG66ZE2UmEwMk/XFt58L Oft/6XIGL9JpzpkOPpDCvypl4EJbHN6ZB0EdGS6Fq5E8R9lRbDWb7tA6fKHzxDKDus0qE2 Sk/ShHXHH4wbiz2Lqg8tjHcQkDvBRNaqnqPjOAMtpYkaXv56BL4thEpmgnsQ9P3YmrzW4+ rJf4NZvh7UxKmB08aiiyixwseqfQNKW0ZZ24E45/O41wDQ3WEARzOJuz5V/7E0LtW9hlUK K6Ovn3wn4biTHVOWzRvKE/7C2uWGXXMZ9W+yVK1rer6M+cep60hSipmxkg1/OQ== 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=1725590381; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lK60KEPIBxjhMR99m85xT7EZBhRDcl16JlZnRyzg4LU=; b=bXsdKFBUSM2BJO4CRIQnhBylH3Cnk4SSteAqIE+z5uj3hHJzuuhgQzK+q/phSlgnWtu4uv Z4+e1bk6NnMIJIt4v180NROu/cK6vegtw1RzoCVV3sqSbTw7Px+QxJxupGcL8ULc8GE7hc YCrsOkuA2/WKRCPLof8s3oRXEcCRJV52MxvtsHtnwHHtt+JYg1CTpp7C2Ot67LSvmYl8+I Q624NBsmGRKQfRyJv9Hr9vQPDEpVxXNyzMOlXs+CUiJPgtlEpY2fpSoJHwCNfvG1V2M1sb rro3eLp4StwDZqJnYcUcciv7s+zaGtQpEi7PR6RMlSZS5l4wI0+HKbHEj+GpcQ== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0L6P0K01z1Q3x; Fri, 6 Sep 2024 02:39:40 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <822de199-000d-48f7-a0bc-afe97d825735@FreeBSD.org> Date: Thu, 5 Sep 2024 21:39:39 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: adding new flua libraries To: Mark Johnston Cc: freebsd-hackers@freebsd.org, imp@freebsd.org, bapt@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/5/24 19:34, Mark Johnston wrote: > On Thu, Sep 05, 2024 at 06:11:47PM -0500, Kyle Evans wrote: >> On 9/5/24 17:51, Mark Johnston wrote: >>> FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's >>> intended for use by the base system, and so far has a few consumers, but >>> not many so far. (As an aside, flua's intended scope is not totally >>> clear to me. Is it only for use by the base system? What compatibility >>> guarantees does it provide, if any?) >>> >> >> Only by the base system (hence the rename and hiding it in /usr/libexec), no >> guarantees except for modules we've re-implemented subsets of- if a >> conflicting name exists in ports, its use must be compatible with that. >> >>> A few flua modules wrapping FreeBSD libraries (e.g., libjail) are >>> available, but they don't provide enough to make flua useful as a >>> general purpose programming tool. It lacks interfaces for interacting >>> with the system (e.g., libc/libsys/libutil/etc wrappers) as well as >>> standard programming facilities (e.g., classes, higher-order functions, >>> etc.). Here I'm mostly interested in discussing the former. >>> >>> I think flua could be a very useful alternative to shell scripts and C >>> code where performance is not critical. It's very good at wrapping C >>> interfaces and thus could be used to make FreeBSD features (jails, >>> bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who >>> don't want to interact with C. >>> >>> It's a lot of work to build up a set of flua modules that provide enough >>> functionality to be generally useful. My feeling is that the easiest >>> way to get there is to wrap C interfaces directly (to the extent that >>> that's possible, but it's usually easy) and expose them in flua as a >>> stable interface. Libraries written in pure Lua (or other languages >>> that interoperate well with Lua) could be built on top of that. >>> >>> I'm inclined to start by wrapping libc and libsys interfaces in a manner >>> similar to luaposix. There, the namespace is partitioned by C headers, >>> so posix.unistd contains identifiers from unistd.h, posix.sys.stat >>> contains identifiers from sys/stat.h, and so on. In fact, flua already >>> has a small subset of luaposix's functionality. Wrapping C interfaces >>> isn't much fun, but it's easy, and it saves us having to come up with >>> names and interfaces (naming things is hard), and helps ensure that the >>> glue code is relatively small and doesn't impose a large testing burden. >>> Moreover, C interfaces don't change much and are subject to >>> well-understood compatibility constraints, which should mean that Lua >>> interfaces built on top of them are subject to the same constraints. >>> >>> Assuming there's general agreement on that approach, the question I'd >>> really like to answer is, what should the namespace look like? It would >>> be useful to provide a posix module compatible with luaposix, but that >>> obviously won't contain FreeBSD-specific functionality. >>> >>> I propose having a top-level "freebsd" namespace for all modules >>> implemented in the base system, excluding posix and contrib libraries >>> which already define a Lua interface (libucl is the one example I see so >>> far; we could import sqlite bindings as well). Then, if we follow >>> luaposix's convention, we could have freebsd.sys.capsicum.* for >>> Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent >>> wrappers, and so on. The posix module could simply provide a subset of >>> freebsd.*. >>> >> >> I think that's fine. Ideally, we probably just import luaposix wholesale >> now once we get the bootstrap flua module situation sorted and we can just >> re-export those implementations into the freebsd.* namespace similar to how >> we discussed luaposix was doing things today, unless those interfaces are >> weird (I don't remember them being problematic, though). > > Could you please elaborate on the bootstrap module problem? > We build a bootstrap version of flua that was initially used to accommodate, e.g., `make sysent` after the conversion of makesyscalls. That'll become more important for the Linux/macOS builds if (when) some or all sysent artifacts are generated as part of the build as well. The problem is that we don't setup the bootstrap flua to be able to do loadable modules (and we don't bootstrap any modules, for that matter), so we need to fix that before we further adopt it. > Regarding importing luaposix, one potential problem there is with > interopability of userdata types, mainly the treatment of file > descriptors (which I would want to use in, e.g., freebsd.sys.capsicum). > For example, in the reviews linked below I went with a userdata type for > file descriptors so that they can be garbage-collected automatically, > but luaposix doesn't do that AFAICS. To me that's a bit unsavoury but > I'm not sure how important it really is. I do think that we could quite > quickly and easily reimplement most of luaposix, for what it's worth. > Ahh, that makes sense. I don't feel that strongly about importing the rest of luaposix wholesale, so I'm perfectly happy to drop that idea; as you note, it's easy enough to reimplement it. >>> Maybe it's better to separate C wrappers from native Lua modules though, >>> so it could be better to have freebsd.c.sys.capsicum.*, etc., and >>> provide higher-level interfaces for FreeBSD features under freebsd.pf, >>> freebsd.zfs, freebsd.jail, etc.. I'm not really sure. >>> >>> In the interest of prompting discussion a bit, I posted some patches to >>> add some example wrappers to flua: >>> https://reviews.freebsd.org/D46553 >>> https://reviews.freebsd.org/D46554 >>> https://reviews.freebsd.org/D46556 >>> >> >> Will take a look when I get a bit of time. > > Thank you kindly. > >>> Does anyone have opinions on anything I've brought up above? I'm pretty >>> happy to write a lot of this glue code or find ways to automate it, as >>> I've already done a fair bit of it, but it's hard to make progress >>> without having some rigourous conventions for the flua namespace (again, >>> naming things is hard). >>> >> >> We should also figure out where to document this stuff (policy, mostly- we >> have a 3lua section for libraries themselves). > > Yep, I added a hacky posix.3lua in one of the reviews linked above. A > man page for flua itself is probably the next step. Excellent! From nobody Fri Sep 6 04:02:57 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 4X0Myl6gxMz5VW3J for ; Fri, 06 Sep 2024 04:03:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0Myl2ZGCz54lK; Fri, 6 Sep 2024 04:03:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 48642vCE083281; Fri, 6 Sep 2024 07:03:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 48642vCE083281 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 48642vPn083280; Fri, 6 Sep 2024 07:02:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 Sep 2024 07:02:57 +0300 From: Konstantin Belousov To: Alan Somers Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: References: <202409052313.aa18097@berenice.pkmab.se> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4X0Myl2ZGCz54lK On Thu, Sep 05, 2024 at 04:37:27PM -0600, Alan Somers wrote: > On Thu, Sep 5, 2024 at 3:13 PM wrote: > > > > Alan Somers wrote: > > > In fact, of all the C bug fixes that I've been involved with (as > > > either author or reviewer) since May, about three quarters could've > > > been avoided just by using a better language. > > ... > > > To summarize, here's the list of this week's security advisories, and > > > also some other recent C bug fixes of my own involvement: > > > > After checking several of these examples, I'm wondering what the code > > would have looked like in some "better language", where those bugs would > > have been avoided? > > > > E.g for the "use after free" or "unitialized memory" examples. > > > > To me, several of those bugs seem fairly complex, and not just a > > question of having bounds checking for arrays or a borrow checker > > for pointers, or something simple like that. > > > > But maybe the bugs could have been detected and prevented if the > > code would have been forced to be expressed in a completely > > different manner by some other language? Or what is your vision > > of how that would be accomplished? > > > > You seem to be saying that certain examples would be solved by > > a better language, and certain ones would not, so I suppose you > > do have some vision of how that would work. > > > > I'm just curious to learn more, since it is not obvious to me, > > and thus all the more interresting. > > > > /Kristoffer Eriksson > > Excellent question. Here's why a selected sample of those bugs > would've been prevented had the programs been written in Rust. > > 2909ddd17cb4d750852dc04128e584f93f8c5058 > Rust uses RAII wherever possible. Variables are automatically deallocated when > they leave scope. Circular references are almost impossible to create due to > the lifetime borrow checker. So bugs like this really just can't happen in > idiomatic Rust code. This can be expressed in different way. Rust makes it too hard to operate on structures that are richer than acyclic directed graphs. I am very interested in proposals of a reasonable Rust bindings for our VFS interfaces. > > CVE-2024-45063 > Written in idiomatic Rust, the lun->write_buffer would've had a type like > Option>>. The only way to free that would be to remove the > contents of the Option, leaving None in its place. So a subsequent > use-after-free would be impossible. The bug would still be present, but > instead of a use-after-free the READ BUFFER command would have to create and > zero-initialize a new buffer. The bug would be immediately obvious to the user > since READ BUFFER would return the wrong data (all zeroes). > > CVE-2024-8178 > Rust abhors uninitialized data. LLVM doesn't even guarantee that a program > will run correctly when accessing it. So written in idiomatic Rust, > lun->write_buffer would either be zero initialized, or it would be allocated > like `Vec::with_capacity(262144)`. In the latter case, it would be partially > initialized during the WRITE BUFFER command. But given the semantics of SCSI's > READ BUFFER and WRITE BUFFER commands, I think zero-initialization is more > appropriate. > > CVE-2024-6119 > In Rust, initializing a union via one member and then accessing it via another > is actually considered to be the same thing as reading uninitialized memory, > and LLVM abhors it. The idiomatic solution is to use a enum (which is similar > to a Java enum) instead of a union. The enum is basically a tagged union, so > the programs knows at runtime which member is initialized. That makes bugs > like CVE-2024-6119 impossible in idiomatic Rust code. > > CVE-2024-41928 > This bug involved zero-initialing a structure, but with the wrong size. > Idiomatic Rust code never uses anything like bzero. In fact, zero-initializing > a structure is considered unsafe, because an all-zero pattern isn't valid for > all structures. To initialize a structure in Rust, you either need to provide > the value of every member or else use an initializer function. The simplest > intializer is often STRUCT_NAME::default(), which can be automatically derived > and is often equivalent to bzero. But all of those methods know the size of > the structure, so bugs like this aren't possible in idiomatic Rust code. > > CVE-2024-45287 > In debug builds of Rust, integer math operations are by default bounds-checked > at runtime. That catches many bugs like this. For release builds, integer > math operations are wrapping by default, but the programmer can also select > bounds-checking. In this particular case, however, a Rust programmer wouldn't > have attempted to multiply those two integers together. Instead, `value` > would've been a Vec of some type, and it would be initialized like > `Vec::with_capacity(nvp->nvp_nitems)`. Note that Rust would only help there if code actually execute a case which makes the operation overflow. So until somebody notes it, the bug is there, in the form of panic in debug build, or 'whatever' in the release. > > 1f5bf91a85e93afa17bc9c03fe7fade0852da046 > Rust's borrow checker will ensure that a single variable cannot be modified > from two locations at the same time, or modified in one and read from another. > This check happens at compile-time, with 0 runtime cost. For cases whether the > compiler cannot determine whether the access is safe, various runtime options > are available, like Mutex. In this case, the function's author actually > performed a cast to remove "const" from the variable. Rust makes such casts > harder, and it's better type system makes them far less necessary. > > 35f4984343229545881a324a00cdbb3980d675ce and > eced2e2f1e56b54753702da52a88fccbe73b3dcb > In idiomatic Rust, a falliable function returns a `Result` type, and the > compiler is smart enough to know when a programmer ignores the Result. It will > generate a warning, and most projects are configured to treat that type of > warning as an error. So bugs like this don't usually happen. They can, > however. A programmer can deliberately ignore the error, as in eced2e2f1e5 , > or he can "unwrap" it. That means "panic on error", which is not terribly > different from the bug fixed by 35f49843432. So it's possible but far from > certain that a Rust implementation would've prevented these bugs. That's why > in my summary I said "about three quarters" could've been avoided. > From nobody Fri Sep 6 07:02:28 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 4X0Rxs5bV2z5W981 for ; Fri, 06 Sep 2024 07:02:41 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0Rxs4YnHz4Fyj; Fri, 6 Sep 2024 07:02:41 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725606161; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FncDpYuN0UltBXxCZmR8D0nw/aeCiVA7iS1Z7AHGr0o=; b=Bqt2TLHMLVLH8wDZqOOYtsPf8UFmhqk+IEYOneqXkZAJCoC8oIh/fqVjD/aa/5APuS6Twn Qn9vkeElRw1NC4T5tKxGSErayBu86ZtwIuVZuyRnqDQ+v5MWja7WWmcE8SrtGuq93Dc5RW yTvXJx/gJJ6rpvyaEp1Tgh6quWcr2BesHqKslCR6Ngv2iG1rT3XGlt05+xMESuAggT8wtD vKe3+ZegBZC4RLpe19rVE4IQzzPonHzhH0HMJ4ynsR2F+OwI7ajNopbNXGkNwK3h1d228V 8eGfYSKkPeqcK0zwykwmfzE0bZOlE/asPQhVp9EgcX4OWOMf6XDv4SZJ+KFdpg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725606161; a=rsa-sha256; cv=none; b=KJvpwT4sk2HHW1PPlex5mTdaz5g2SV/Oa7nNJz5KBgeWPb/eMgZSYMhtw+9z3V3Wg7UTlM 93AompjhoiBboQQh7LNd/eE0Y9SPdHUYt+NEWoElUWc8VKnaSMVXifdSkQXvHFbkEpRVPa HFs8LusBXnpR/t269+TOmKWCAese2ysqk46Wa0aHOUkDtBCru/o3ceQ77tqu/KGWymiCbk bDGWKCt1l0rnsWX5itLN6miOTfkglQzHeE9qVMZWi6v/Jxui+Qe5vUYZXrFAqV7+FrD84C h7fMN6qP6c5muAwKm6EIO4QaB9CQ6x4fBBhZcaxUXUWMdjXGqBlKND4QUdGWLQ== 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=1725606161; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FncDpYuN0UltBXxCZmR8D0nw/aeCiVA7iS1Z7AHGr0o=; b=jeqwKujzKeFiLRGHinyPgS7lOCWMmh6ywnTLzYIhQO7VyBnq5sig+iwVR19OkEaGz3dRSQ DooSIZtDaqUQVlNfjmMIKHmKaFDfKi+AUQCquQNM9JwRyeibta7HuTV8d8clpYJbC3TvdS WDpEnc6CWIQO70amOMtDPji5b9XkJbbYXqcmXCiYbKxe/DHRReq9CEICMcKziK+n6IxMba KIRnr6XojKEyLmeoND471T5F00I6Dq95o/h9mYJoP5J1WiLF3Vh2oZ71TNeYP6Mr3Ulkq1 QNVQo4LNhOC0l1zICwASHmOgKG94gLZLUshsNG5+ojE4iURXikii/LFmIAAY6A== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0Rxs41JPzH9g; Fri, 6 Sep 2024 07:02:41 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id D471064F7; Fri, 06 Sep 2024 08:02:40 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 08:02:28 +0100 Message-Id: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> References: Cc: Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org In-Reply-To: To: Alan Somers X-Mailer: iPad Mail (21G93) On 5 Sep 2024, at 22:13, Alan Somers wrote: >=20 > I used to check it, years ago. But I gave up. The UI is too hard to > use and false alarms are both too frequent and too hard to suppress. > Plus, it's a real drag that I can't run the tool myself. Instead, I > need to wait for the next scheduled run. In general, it=E2=80=99s very hard to add static analysis to existing projec= ts. The property that you want is that there are no *new* static analyser er= rors in a new commit, but that=E2=80=99s requires tracking all of the existi= ng ones. In CHERIoT RTOS, we run the clang analyser in CI as one of the chec= ks that must pass before a PR can be merged. This is possible because we sta= rted doing it very early on. It may be possible for some individual parts of= FreeBSD, but when we started with Coverity I looked at the reports and the f= irst ten I looked at were all false positives. There are probably some serio= us issues in there but the effort to find them is high. For a new project, t= hat cost is a small incremental cost in each commit and code review (if the a= nalyser finds something, reviewer has to agree that it=E2=80=99s a false pos= itive). David From nobody Fri Sep 6 07:05:07 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 4X0S0v4nqlz5W9p3 for ; Fri, 06 Sep 2024 07:05:19 +0000 (UTC) (envelope-from theraven@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 4X0S0v46Hpz4Gvn; Fri, 6 Sep 2024 07:05:19 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725606319; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1sjyHOhlCOUHt8R8JVGrLk3uIXE2ZcTGHV0wAq01lNQ=; b=Cxcj3dM9JF+NeyL/d+I7OWQPlDtGfpVQ/l0gVTTn7w8LvQZUjLFx077Pxn/QA5ptVHIHEr zbaHXcRQJ6M+n24DL7WnLeQPFLMm6b3fSvlpQqhdEzKsZKVh5lrBechzGwzchzun/IGHqL UnudEpUjED3qIjp+fOUAExYsXW9j5wd8IMJlEphQ++u+KyXGi47z/b6adsufeD34ZWeTZA r45sd9/dmlssfEDduPbG+cTFa/bGPXAYxzMWpIZzdYt4qlFdtOAwuGEVr1RF/aRw4GyQ1T SPzqVXGVHnDvkwmVWP3xHYEkZMofS/rKNp6Y+rG0LAZ/cDIsOk1MSASzdQnc/Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725606319; a=rsa-sha256; cv=none; b=eqDKDgcTdQWZkSvWI4iVz8LIj8N+inGkbIDb7bB/U0f27f/uT9rkpqQqjPObOsucW/Lspy 6635LPCB17OtHeYtZwsI8LgVYNgV+WKunhbWOG9JOdhd4CUCgqre84ppuKqo1xU8ryavsf Mfy4va84rDm2bhArRR0P5A2ZPyZerrC7m1Ix9u4nLBUxzlnWeyFCmJFs5mm/BCIgTBElss 90YN9+TmCqw/yJHjlnmXop36aLt6O+pTNMbWrn8bjfpluqC0+E9L55AQ4RwcaStSbg04E8 +P+KuHwSxEK7HZ0BIUoBqYAc7d5ydo2IFXPBpX1fXHTDWlarZ4sGyjhgNlbO3w== 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=1725606319; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1sjyHOhlCOUHt8R8JVGrLk3uIXE2ZcTGHV0wAq01lNQ=; b=vkz8V5oUWzM19AKl3tb1n41ooEUnECsjfnMUWRSo46PaBiHCczhCao/gveqlXei/2ptxsI TLjpvkq0osXzt8TFOQxD9NID/aWstgRXonTyog7MaTZ8rstvHETsrL47nczO0MuInet5wT EzH4bVShaDU+P4Wtfs4YiR8FYjAdfZYV0+9ByfZ8KAa9vHo0tnqJ6EWbcpGKf/DOuAxIMf 9A5pnu2CesM2c4lrakJWdTbsYp0X02eL7gwPrz/fi+s4Y2qNecLiHQ4eDiw4K0EEt4+Kxy Ddv7HSoo8+4lwmYLyb7elPvFIXk4o9L1JIFPI2qn01hAoZ05U/xEPych40q8RA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0S0v3WgSzG2X; Fri, 6 Sep 2024 07:05:19 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 2DFB964F8; Fri, 06 Sep 2024 08:05:19 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 08:05:07 +0100 Message-Id: References: Cc: Alan Somers , FreeBSD Hackers In-Reply-To: To: Warner Losh X-Mailer: iPad Mail (21G93) On 5 Sep 2024, at 21:17, Warner Losh wrote: >=20 > Without enough resources, > the rewrites will be crap and nobody will want to use them (or maybe even > FreeBSD). The rewrites to date have lost functionality (though maybe not > functionality that's important) relative to what they replace. The new Windows sudo tool is a good example of this. It was written in Rust a= nd, as far as I know, no one has found any memory safety errors. Some large c= ategories of potential vulnerabilities were eliminated by construction, whic= h is great. Unfortunately, that didn=E2=80=99t stop it having a terrible sec= urity architecture that allowed remote privilege elevation. You don=E2=80=99= t just need competent Rust programmers, you need competent Rust programmers w= ho are domain experts. David From nobody Fri Sep 6 07:13:34 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 4X0SBf4xdLz5WBqL for ; Fri, 06 Sep 2024 07:13:46 +0000 (UTC) (envelope-from theraven@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 4X0SBf38HDz4JdS; Fri, 6 Sep 2024 07:13:46 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725606826; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GnlbFm2JwOQ8tZNzYPmrmpf8OXzU5v7YNFmwtC/Rda4=; b=U1bR40sLIuiV7i8fqEzHOt7O00KBVQS6Muzmdsg5MQaVZysdisS8qxwFoxTCPJ1i2HKfNk 4BPVAr5poVTAk1Qz4DhwA7Aqqu6BzR32RGdO4R/7B0Q3yZh9WjG/yYc8WW/7VGsOp+dY2R sclPK2vLM+xhevEtUlGUmYt2GdPSfWbFgfefjdrDXmLNZkhIqQF8v6fV65dVCdDI1n+6Ww i8hT7ld2KWy3dnIvCcDvTBLxx8aw/4eDg2QieDTCRl0mTEX20J0Y6qZaUrjAE4AdUHR0fX KoExHhXSAPI57uuwBLBI7o8hYvXlN9dK4zlz10UOWmh6Zv6JyWze8M6xQRpo0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725606826; a=rsa-sha256; cv=none; b=JEErFhVrqenW9sNiHQ6oaBW3Vzp/Zy5MLGPHHxzx4Jk9jW4oRSnKVhuXxGKmSY7Gzqh0Vu ZUazkTToACCc+LQsNhx2kSaZECm/qNs33Mo2YrvFwc4KykIkj2ZUrD8DjBEiQ8WQu/4LSJ v+PAKphTrjU6V3z2MBNe6FVGd2fYLoSVYr82X4iUYicDFJbmUJ4o9kXiNq3CIJf1edtW3k sC6e/8gzhMpWowXtsGeq0oH0d9RVhUJWgdnZv7K7Lz8bgauEA0ZfWAUYNJolm3MKCat9la FDLLP2vfJWToIXaDoRQIjuOm4iX3fNYfMvZhIL6h6vu4QbuBgnxP1CFeQ0ivmA== 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=1725606826; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GnlbFm2JwOQ8tZNzYPmrmpf8OXzU5v7YNFmwtC/Rda4=; b=jrYR3nESFmY8eD1qru746congVZAsxgGtuCtCRd94T0q0edLOU9KpBUdyViH3oKp7Ydixp C9UgbfxZUWYFYwNUqTdRetKn/CQaqcR7oRxG/x29Hk6Yiim6//yBhBTCY9mmOIr3Z/GZKH nqUuydfS04EoCklYEzvHyaDpzVApV+AH/90/8/f22gFtdZea2DVS5YJxYFuxXC0l8SGFFB mdwqNIh+P7NajIgCWRDg5RhW6bw72xHwFSPrWDGhNyUHy9/38LTdQbtX6iPYVwktMblQ2n gXHA9h4SeHM03mvQ1rRnmT2HPcglMvy7JrqWgK7o3T7tJym3JkEcJyeuA3Z24A== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0SBf2bvxzHdx; Fri, 6 Sep 2024 07:13:46 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id BACA464F9; Fri, 06 Sep 2024 08:13:45 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 08:13:34 +0100 Message-Id: References: Cc: Karl Denninger , freebsd-hackers@freebsd.org In-Reply-To: To: Alan Somers X-Mailer: iPad Mail (21G93) On 5 Sep 2024, at 20:50, Alan Somers wrote: >=20 > I think you are misinformed about the runtime costs involved. In > fact, Rust's overhead is quite low. It=E2=80=99s very hard to get good apples to apples comparisons here but the= main thing to remember is that C and Rust compile down to the same instruct= ion sets. For spatial safety, you have basically two cases: - Things where the size is statically known and so all accesses are in boun= ds if their offsets are known. - Things where the size needs to be carried around with the object. There is nothing magic in C here. You either have fixed-sized things and a c= ompiler will be able to statically bounds check (though will typically only w= arn for invalid ones) or you carry the length around and check it. The diffe= rence is that Rust or C++ can express both of these in the type system and s= o will always insert bounds checks for any access where they cannot be prove= n to be redundant. The cases where you will see a difference are the ones where the safety depe= nds on some extrinsic property that the programmer knows but which cannot be= expressed in the type system. In C, you will do an unchecked access. In Rus= t, you *can* do unsafe things with raw pointers, but usually you won=E2=80=99= t, and so you=E2=80=99ll get bounds checks that are redundant. Assuming, of c= ourse, that the assumption that the programmer made is correct and remains c= orrect as the code is refactored. Which it often isn=E2=80=99t, and then you= get security vulnerabilities. David From nobody Fri Sep 6 07:19:44 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 4X0SKb2VJlz5WCR5 for ; Fri, 06 Sep 2024 07:19:47 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0SKb1bwWz4LB7; Fri, 6 Sep 2024 07:19:47 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725607187; 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=lZDg1SHq/48COzahB5urrlQfl5nnzXdsCO9uxRi+Q3U=; b=EZ4Lq7MJmqbvm1kNjyQPWBQLQZHLUgYHiZmO44H85GTzg0G5NkIlThAELLNOd89pSifA74 ISjlsj+H3yPiVhax2lZ266B6liBo49MtUEzoLL0sSipR6K3anffJaY3pQ8PXlyE8KtWRYV jL9sMKIXeWZPAoC0M3XUegjtjK4njMb5OG7Q1Wv8uTrXE21yTLF2aJXecMl/qXghRKbek6 hiXySbT/2NxREO1mCVgMfD8/ZhcFBek9mYZKfcDr7UDWOMSqRU/CuGc4/Nj1afo3ze1hI1 WTriZj4WUANjo1LXJRq8n/K2dMj+weJIE9cbFekllB/6Z7qYlsVvNzib7WYUeg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725607187; a=rsa-sha256; cv=none; b=eUOX9SKTkCyd7k7zMPMIq03m9Re7BMkpbLv3WekSy/4Td4e2xDqnciPb0laHDTy9VU5ERN ysNKQCiD1gVSvCayH4iHtKtrObadukgjTC/FhfFXy+xHhMtrLr1mlyLVF2rQWmZHqz05PS 4k1TAY0ztIHDumYOrfQgse4gAq9n2NnkoVt2VF5HWga9KofszN30nBMRexgxLfoBYbwgPT yJHnypWjpsB0VCcJEWdqrn1Z9nHpk26EqRmVyZ40Exv41+LCfMpHI0yw+b7ajIoN6DhqOF 5Syl/nGTv3sUH5bSTIRxh3iE6F5Nl6u1sv8ZSmCAHN29grA4LkcZ8YXnrV/bjQ== 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=1725607187; 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=lZDg1SHq/48COzahB5urrlQfl5nnzXdsCO9uxRi+Q3U=; b=yrI/e2pz7qZ1dX46i3qlGfSq3+UwV0K5CzXnio7x0RGpSYDnK02de+uIzrOgAOyJlp5/yi RG0BudGiFUnGjeUvALlAfnMjVPlEROEAIjq/9TTAjwbIS9yOTgIoD3mcb6Lk9SBn3wfmNi KW103qj596xP7mE2FffF2lJc4sO0Ahi+cswyE0By0wnoIzPBH7+aV7GRfA+j50K2+cqXl6 k+mZRgN5wfas7bcflaJVGPunjQYxdcqa+md9fIcZ7ROPyBgkRtJBXUCp/MQE7qMaUATeUc L+2xCu3uV9Y5gIbTx0eh5DrBRaI6kWPzz5o87hMy9+gUWbegnxx6bYi1ghW1+w== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (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: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0SKb0W7KzH9m; Fri, 6 Sep 2024 07:19:47 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 609CC23B1CF; Fri, 6 Sep 2024 09:19:44 +0200 (CEST) Date: Fri, 6 Sep 2024 09:19:44 +0200 From: Baptiste Daroussin To: Alan Somers Cc: FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu 05 Sep 12:09, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: > Jumping on this one, I think at least that is my understanding from the previous threads, that using some rust has not been rejected, so keeping discussing at length and trying to force convince people will not lead to anything that would make progress on the rust integration process. On the other side there have been many "work to do, problem to solve" that has been raised to allow to make it happen, so far I have seen none of the rust people actually trying to work on solving those issues, I would have expected now to see patches, design proposals, questions and so on to move forward. For the people who want to see rust usage in base, it is time to start the actual hard part if you don't want those threads to be seen as "yakafokon" (as we say in french, I don't know if there is an equivalent of it): - make a plan - write patch and poc on how to integrate to our build system - discuss with the people who volunteered to help on the build system, on the release engineering, or on the packaging side. - create AND lead the working group to make this happen. Best regards, Bapt From nobody Fri Sep 6 07:25:03 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 4X0SRr2sxcz5WD05 for ; Fri, 06 Sep 2024 07:25:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0SRr0Jftz4MBr; Fri, 6 Sep 2024 07:25:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id BA2E28928B; Fri, 06 Sep 2024 07:25:03 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 4867P3ul040678; Fri, 6 Sep 2024 07:25:03 GMT (envelope-from phk) Message-Id: <202409060725.4867P3ul040678@critter.freebsd.dk> To: David Chisnall cc: Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> From: "Poul-Henning Kamp" References: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> 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: text/plain; charset="us-ascii" Content-ID: <40676.1725607503.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 07:25:03 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X0SRr0Jftz4MBr -------- David Chisnall writes: > On 5 Sep 2024, at 22:13, Alan Somers wrote: > > = > > I used to check it, years ago. But I gave up. The UI is too hard to > > use and false alarms are both too frequent and too hard to suppress. > > Plus, it's a real drag that I can't run the tool myself. Instead, I > > need to wait for the next scheduled run. > > In general, it's very hard to add static analysis to existing projects. Only in the sense that if you want it to provide value, you have to clean up both the code and the list of findings. I did spend some time on Coverity+FreeBSD back when we initially got access and I was sufficiently underwhelmed that I stopped. Coverity has gotten better since then, and it has found a few serious issues in Varnish Cache, but not much. We generally keep the Coverity list clean. One thing about all static analysis tools that you will soon discover if you use them seriously, is that they are all "opinionated" and if you disagree with their opinions, they become as tiresome as a drunk uncle. Coverity is not sober IMO. I will also note that almost all the blame for C's current status lies with the standardization efforts, which almost seem hell-bent on destroying the language rather than improving it. More and more stuff becomes "undefined" instead of taking a stand and laying down a sensible rule. Obvious improvements do not happen: After a quarter century of standardization, C still does not have a way to explicitly lay out a datastructure and specify it's endianess. I guess because C never interacts with hardware and protocols or something ? Why havn't C gotten a set of rudimentary classes ? Are they afraid Bjarne will stop sending them X-mas cards if they adopt a good idea ? How about type-safe enums ? Integer-ranges, a'la PASCAL and ADA would be a great way to tell the compilers what to look for, even if they are used for nothing else. But nope, can't have any of that. Poul-Henning PS: Recently I have not been able to use the Coverity U/I because of some disagreement between my Firefox and their webcode: ERROR TypeError: getColumnCssRules(...).left is undefined applyColumnWidths https://scan5.scan.coverity.com/main.55109ab457b762= b4.js:11 updateCanvasWidth https://scan5.scan.coverity.com/main.55109ab457b762= b4.js:11 updateRowCount https://scan5.scan.coverity.com/main.55109ab457b762b4.= js:11 resizeCanvas https://scan5.scan.coverity.com/main.55109ab457b762b4.js= :11 finishInitialization https://scan5.scan.coverity.com/main.55109ab457b= 762b4.js:11 initialization https://scan5.scan.coverity.com/main.55109ab457b762b4.= js:1 Has anybody seen this ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Sep 6 07:25:41 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 4X0SSd2VWWz5WCwf for ; Fri, 06 Sep 2024 07:25:53 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0SSd05Cpz4NTp; Fri, 6 Sep 2024 07:25:53 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725607553; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=usWt3BxVq8Fhxk6XEmNoB/to/8Hp+wXIMLuocVzYc5A=; b=GAXXCIQNTN1BbIbFyp07ittVKi90q+xXOK178neSyrRN3wU2wKNIXfmT6gYdJW80ksO6QJ OCyDNYra93iRJmSjKmGmqZctc8un/OsoYO5dKeOnZTRkCpK2hCzEzTIVttyY5us1B0mBCl v1O+uhWw777BPULm9KuqRMdu/qcd+OnqpCm0x2jAlnWIVr0scWVBJeAYPaw3PWGXQwPk2J eZr/Xbn1wciPWzUQJR7ErO1QRKcswGBQIyykYQTLpaP+/q7v35NGXl+zBb3EnDC7bMwg1r DzFCip79+vjmm/2KIMKAsDP2K5Q0MIXpskCZeV4fq1erKQELEBQJWuRT/sQlPw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725607553; a=rsa-sha256; cv=none; b=q+yqkIW5TC0wkVIULEa28qjtudeGJ2QkDn0vodu7kk0NdihIE3h8Qhg9QnoTi7cfX0ijzE NWEVQofLYOJrDfTUx6G9jVLaGwmJ3btIXCj6RA2114QR5RpzKGEigMetVIt2T35yVU5mvf dPYUVwLPoMELpR09ePjIin7YRCPW2Z0+EnnHw2Aga8wUT8AZhqSu09NkFd/oPwAzFEvEkP 9zsx7vFpVRnF8EbfdO8ZMZ+nf4n4Kl1BjPLuDaFTry/Olq/8OkqARFakdlsk29OfLGM/XT FxivFJnQ11tnXHdXTeO2Pu1/CbmEyRte3TYdn5t/s4VjTUmfJB/5BTXC6FRy6g== 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=1725607553; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=usWt3BxVq8Fhxk6XEmNoB/to/8Hp+wXIMLuocVzYc5A=; b=F779sDiw/GLuhdf4jc4vEEQiR8AKGPqe8dbUwTfd+bDlHUjNoRLStMqN6hwSBmdcaTHIGn Bb5DIbtYtoTMVxasLVk3GqBAzf7ckL5+3z4v2Lg3MOeJ91tPXus4As4RCd9Gdz4U54yOgI a+5aGeKMS23BN/kLb0qg4EVi2uF1003vru0Mzs7N1kEBW+4Um/dBdQ8t/6IhP7sOxNZ6wv AYGn7pCWX15E91iE63Hm8YSgl9kg5nzReqkBPYmJGqdwYOaDSJNsuGvj2kFit7RrFaWGX5 T2XViWMOTRNmd19kgY29McuXXMA4OdP4GEaqsZMfLOU0UMohj5hFu7di/wBfTA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0SSc6f4RzHwB; Fri, 6 Sep 2024 07:25:52 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 50C1764FA; Fri, 06 Sep 2024 08:25:52 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 08:25:41 +0100 Message-Id: <87E7BC64-662C-4598-B778-0D8B12B777BE@freebsd.org> References: Cc: freebsd-hackers@freebsd.org In-Reply-To: To: Karl Denninger X-Mailer: iPad Mail (21G93) On 5 Sep 2024, at 20:20, Karl Denninger wrote: >=20 > To argue that the answer is to put a diaper on a child so it does not drop= excrement on the carpet is to forever treat said human as an infant without= control of its sphincters.=20 Not only is this argument insulting, it=E2=80=99s also unhelpful. You could m= ake the same argument about structured programming. Good programmers can hol= d the entire control-flow graph in their head, they don=E2=80=99t need a lan= guage that enforces a call-return discipline. Or about C=E2=80=99s decision t= o have multiple data types rather than BCPL=E2=80=99s single WORD values: go= od programmers know which things are addresses and which are data. Good prog= rammers know how they laid out their data and don=E2=80=99t need struct type= s, they can just add constants to words to get fields. Saying that you want to use all of the safety improvements in system-languag= e design up to the late 1980s but none of the ones that came later is not th= e compelling argument that you think it is. It=E2=80=99s much more helpful to think in terms of cognitive load. You have= a finite amount of brain power available to work on any problem. You have a= a machine that can handle any of the mechanical tasks. Do you use up your o= wn mental resources on things that can be mechanically checked or do you let= the computer do those and let you think about the underlying problem? With Rust or modern C++, I spend far less of my time focusing on low-level i= mplementation details of data structures or on memory-management policies be= cause those are abstracted behind types. I can change them later by swapping= the types out. I can focus on the important bits of the design. For the sam= e amount of effort, I get better code. Going back to a language without even RAII, where I have to manually clean t= hings up on every error path requires me to write code that is entirely gene= ric boilerplate and wastes my time writing it and reviewers=E2=80=99 time re= ading it. Going back to a language that doesn=E2=80=99t give abstractions ov= er data types and requires me to write a load of boilerplate that could be a= utomated, which wastes my time, wastes reviewer time and makes the code more= fragile and harder to refactor. You may enjoy digging foundations with a spade as a proof of some aspect of y= our self identity, but the rest of us will use a digger. David From nobody Fri Sep 6 07:41:44 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 4X0Sq84Tfgz5WFN5 for ; Fri, 06 Sep 2024 07:41:56 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0Sq841Tzz4Rxk; Fri, 6 Sep 2024 07:41:56 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725608516; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QMsZwDOdbWr+5Wp57aZJAuYIwDyJEWkQdBeDYrhFujA=; b=vqxnfR0Q4WE8rISm/dabOVTubFqYQq8dEN2UdtAN20x7Fqtpasesz4kJMsqEJb49xJly0C eaIOkQAjGNhquUfa6mT0hpSOzJAfKFzymwtsOJkzedxOKwwMjdHcVS7UhavF64RO43+JRk uv2G1alGk+UNEUxkyuI/XJvs1LFsSgoihWE8I3lEqo5lj4LiNSiuD2Fq5kOEol2FV7we9A q+gcZSXwVx9EHDhSM78IQGprjh68jt+1Zsp2Oq5+Avw+iDjAtcOauWOHH/K5aW5vSamorI Tts5CD2va9GJt/8kE7qMGuAoO67ejZ7ukQ7vYv+wO1VG/r/tj4+XVHt9/f6uKw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725608516; a=rsa-sha256; cv=none; b=Jm5bYhaa0vG8jDRCQZYeY4agqGFm3sJHQRqqaJ6BSlmxi2A2kFXtied3jvrlYKHZSzOdDX +LnzzlVTLCkSDy+k9/XNJn9q4LkpaKSjVBsh2xNaXQvzYJcErrz0NlPgsgQeB20o3Rc7hO jFGrNV8WsHH1au5kedkGHPvDh7eQQ8wfRgzqLVGDMYUn0qUn6+WzFmXTfHVzTxn+N1PHwq nOGNM3qFmU7ZWT+e46LYHB8fygvd2+/kRhTJlQ+FcDdPAm1qhEX0aWOjmal6Sc+MWradMu h9c+BrlyvFoua8LOEnAo5VZhCmKJH79alIVjc9emKH8uJPFkx21Sx7kdr4KP0A== 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=1725608516; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QMsZwDOdbWr+5Wp57aZJAuYIwDyJEWkQdBeDYrhFujA=; b=QJOm/uHd7Fz8bDpquhDxQPaszuNQZ2N4xBNQHJW7ieDl4UM7QBC8DbjEBOmMX3RACVYxWo 5yeU1YuC21UDF8EtX+mvJ4y0O+axOxKO+UIBNETt6X0IhFbxFMHmGgGBRdaspOBwkm5sy3 KicSRG0n3JUMg/r5vqYkG4HAgMpcqpICRKKpyw9muwV2k/KnFW3Weq+Nxh3UppvxuPEiQ+ InusgyiO6ulgxvZ9qOV5ETKyJ+lDYa4Uit0SVhnNrjIDNlAzUbhHkfHnO3PCAYBkxpl/dn WrTUs5hn1GPuvD5OfPDhvhfz+DRzKQEVrI7iWhnpZGKb37sPDtVxVnWLcvt9nA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0Sq83ZvmzHSD; Fri, 6 Sep 2024 07:41:56 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id BFB4464FB; Fri, 06 Sep 2024 08:41:55 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 08:41:44 +0100 Message-Id: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> References: <202409060725.4867P3ul040678@critter.freebsd.dk> Cc: Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org In-Reply-To: <202409060725.4867P3ul040678@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPad Mail (21G93) On 6 Sep 2024, at 08:25, Poul-Henning Kamp wrote: >=20 > I will also note that almost all the blame for C's current status > lies with the standardization efforts, which almost seem hell-bent > on destroying the language rather than improving it. As someone who is involved with C++ standardisation and so periodically hear= s things from WG14, my impression is that the people who care about the thin= gs that you list have all moved to C++, where they were solved problems at l= east a decade ago. The people still actively driving C are the people who di= dn=E2=80=99t leave because they don=E2=80=99t want these things (and, increa= singly, C++ people who just want to make sure that C doesn=E2=80=99t diverge= too much from being a subset of C++). It=E2=80=99s trivial to write a packed struct in C++ where the fields are al= l BigEndian that do byte swapping on implicit conversion to and from T, f= or example. Integer ranges can be implemented in the same way and there is a= proposal to add them to the standard library that looks nice (the ranged in= tegers are a small part, the proposal is mostly about units and quantities).= Having written a kernel in C++, and worked on two in C, and read a reasonabl= e amount of one written in Rust, I am firmly of the opinion that C is absolu= tely the worst choice for writing a kernel. This was not true in the =E2=80=98= 80s and it wasn=E2=80=99t true even 15-20 years ago, so the question is how t= o move from where we are to where we should be. The strategy document that I= coauthored at Microsoft recommended the following: - C++ conforming to the Core Guidelines and with static analysis for existi= ng C/C++ projects with the C parts incrementally migrated to C++. - Rust, C#, or TypeScript for new projects and discrete new components with= well-defined interface boundaries. - No new C code, except in open-source projects that accept only C contribu= tions. That=E2=80=99s probably not quite the right shape for FreeBSD (at the very l= east, I=E2=80=99d recommend Lua instead of C# or TypeScript in most places).= David From nobody Fri Sep 6 08:16:12 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 4X0TZx5BwWz5WK85 for ; Fri, 06 Sep 2024 08:16:25 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from fhigh3-smtp.messagingengine.com (fhigh3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0TZx4j1dz4YR6; Fri, 6 Sep 2024 08:16:25 +0000 (UTC) (envelope-from antranigv@freebsd.am) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id 37E4F1140344; Fri, 6 Sep 2024 04:16:25 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Fri, 06 Sep 2024 04:16:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.am; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1725610585; x=1725696985; bh=sDmnid5Ozr oM+ujfDb1fnRA90hN9LS4mZaQk4FXesco=; b=xAvC1xsdZqh0lmYdE83dMTXrbY AEr+jAgmWM0DbgF47FZUnpY2kG8stCo/U1ciaiGBfjDsIylRyejiA0OeTXRBXZJl m879zbf6cSjvzvylLFPVIvYvJQG/EM+2aExgLv9DdmYoPMeU948KFjv0/gTNVVBD Nxs9m+isoB1pREo88fwyDvENYkQAHgIpKoCFf1uHdPkjIjV4ZkojvyEMM5oPKtjX mLkThdGmK2JlfH0fqU/7Mx+rTbIGUpArEoIsmXOWqd9dCbQ4xTdYbXezYgqcn+0/ lXEJBDvkp5L1EmLjJFrdwT9F2lfHbK9UZ5gVjaTmlHnOHtckPD//8xlhvSEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725610585; x=1725696985; bh=sDmnid5OzroM+ujfDb1fnRA90hN9 LS4mZaQk4FXesco=; b=V7TT0ka5oI+PYgCqMvV8iEhKdhz6FdCxz7wMo4Cvm8WU Bod66Ng2B05RrQDaTvajiaSW7w26K9SYR4UIn9C9yVk2PT2mgCDW0D5Y4p5tF3LU t8Lt5OasR81xZ712SclQR8FdF4pjjHPbGEvPVq2AAONFFoqw4KK3XMfTZhwyL0sp 1YgINHnCXgNhEGRh8zCFdNx7oNkalPUQMKTkH43hoIiS9sRPO1P0g/hWR7PGGnyw No0cdq7uE/NyV/oo9wPFfcs4lF1+eJHspwwMzGGGenYy3J6GdRtFqM3l6Jao/PFP AXubwaNkBO+p211qgc2Ou/BK0+HgFmAR4i7ZgzYJBQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiuddgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptggguffhjgffvefkfhfvofesghdtmherhhdtjeen ucfhrhhomheptehnthhrrghnihhgucggrghrthgrnhhirghnuceorghnthhrrghnihhgvh esfhhrvggvsghsugdrrghmqeenucggtffrrghtthgvrhhnpefgteekgeefvdfgjedvgffh feelfeefudfhheevueeggfffgfdujeeiteevudeuieenucffohhmrghinheprghnthhrrg hnihhgvhdrrghmpdhfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprghnthhrrghnihhgvhesfhhrvggvsghsugdrrg hmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegr shhomhgvrhhssehfrhgvvggsshgurdhorhhgpdhrtghpthhtohepfhhrvggvsghsugdqhh grtghkvghrshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ibc494664:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Sep 2024 04:16:24 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) From: Antranig Vartanian In-Reply-To: Date: Fri, 6 Sep 2024 12:16:12 +0400 Cc: FreeBSD Hackers Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4X0TZx4j1dz4YR6 --Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alan, I agree, indeed, that we need better languages in the FreeBSD system. C = has=20 done its job very well in the last 50 years, and I think it will still = be=20 useful in the next 50. We can=E2=80=99t just =E2=80=9Crewrite=E2=80=9D = everything, but we can rewrite the=20 critical stuff. My question, however, is =E2=80=9CWhy Rust?=E2=80=9D. Rust is not the = only memory-safe language=20 out there. There are far better options for an Operating System like = FreeBSD,=20 where the language itself is way more stable and has less =E2=80=9Cmoving = parts=E2=80=9D. One of those options is a programming language that=E2=80=99s even older = than C by a=20 year. It=E2=80=99s Pascal. Yes, Pascal has a large ecosystem, but the = compiler itself is=20 small, and the language is stable. And the FreePascal community treats FreeBSD as a first class citizen. I,=20= however, have seen many issues with the Rust ecosystem when working on = FreeBSD.=20 I=E2=80=99m sure these issues will be fixed in the future, but for now, = the community=20 thinks that there are only three Operating Systems on the planet. And that=E2=80=99s just one option. Another one is Modula-2/Modula-3. It = was part of=20 FreeBSD two decades ago, and it is still a very stable and a robust = language.=20 There is even development happening to modernize their toolchain, but I = don=E2=80=99t=20 think that we need that. We can indeed use it =E2=80=9Cas is=E2=80=9D. Finally, there=E2=80=99s the last child of Niklaus Wirth, the Oberon = programming=20 language, which solves 99% of all C problems. There=E2=80=99s a compiler named =E2=80=9CVishap Oberon Compiler / = voc=E2=80=9D. I made sure that FreeBSD=20 is a first class citizen there about 8 years ago and we=E2=80=99ve been = using it on=20 production for 5 years now. One issue with Oberon (and its marketing) is that it relies on a = =E2=80=9CGarbage=20 Collector=E2=80=9D, which is not that nice for a low-level system = programming language.=20 However, I learned lately that the GC can be fine-tuned to make it = hardcoded=20 during compile time instead of runtime. My team is also willing to write a PoC of simple FreeBSD programs in = Oberon as=20 a proof that it works. I already have a PoC of a kernel module in Oberon = that=20 compiles on FreeBSD using voc. My point is: yes, we do need better languages. Yes, we do need = memory-safety=20 and better tooling. But is Rust the answer? Don=E2=80=99t want to sound like =E2=80=9Cbragging=E2=80=9D but the Rust = ecosystem is very new=20 while us, Wirthians, have been doing memory-safe programming since=20 the 80s. My personal problem with Rust is that the compiler is unstable (new = keywords,=20 deprecated keywords, but this can be solved, like you said, with version=20= pinning) and that, oh my god, the language is now massive. I like C = because I=20 *don=E2=80=99t* like C++, because I don=E2=80=99t want to learn for 2 = years before using on=20 Production. With Pascal, Modula and Oberon, I can just read a single = paper, and=20 start using the language. I=E2=80=99m sure there are other options as well. such as Ada. I=E2=80=99m= sure there=E2=80=99s more. If we=E2=80=99re gonna do the work to import a new language into FreeBSD = to solve C=E2=80=99s=20 problems, let=E2=80=99s have a look at all the options, not just the = ones that have the=20 budget for marketing. If we chose something based on marketing, we = wouldn=E2=80=99t=20 choose FreeBSD in the first place, am I right? ;) I hope this gives a better direction for the future. Kind regards, =E2=80=94 Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C > On 5 Sep 2024, at 10:09=E2=80=AFPM, Alan Somers = wrote: >=20 > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. >=20 > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. >=20 > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. >=20 > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: >=20 > Buffer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D3aaaca1b51ad844ef9e9b3d945217ab3= dd189bae > CVE-2024-45288 FreeBSD-SA-24:09.libnv > = https://cgit.freebsd.org/src/commit/?id=3Da06fc21e770a482c8915411ebc98c870= e42dd29b > CVE-2024-41928 FreeBSD-SA-24:10.bhyve > = https://cgit.freebsd.org/src/commit/?id=3Daf438acbfde3d25dbdc82b2b3d72380f= 0191e9d9 > CVE-2024-42416 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3Ddb87c98168b1605f067d283fa36a7103= 69c3849d > FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D5c9308a4130858598c76f3ae6e3e3dfb= 41ccfe68 > CVE-2024-32668 FreeBSD-SA-24:12.bhyve >=20 > Integer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D36fa90dbde0060aacb5677d0b113ee16= 8e839071 > CVE-2024-45287 FreeBSD-SA-24:09.libnv > = https://cgit.freebsd.org/src/commit/?id=3Dc3e6dfe55c0e81d0717b0458bc951283= 84c3ebe8 > FreeBSD-SA-24:14.umtx >=20 > Use after free > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D670b582db6cb827a8760df942ed8af00= 20a0b4d0 > CVE-2024-45063 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D62f40433ab47ad4a9694a22a0313d576= 61502ca1 > CVE-2024-43102 FreeBSD-SA-24:14.umtx >=20 > Uninitialized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3Dea44766b78d639d3a89afd5302ec6fef= faade813 > CVE-2024-8178 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D0f2b2276abc305905e7d88619a7abca2= 6b0dd7eb >=20 > Memory Leaks > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D2909ddd17cb4d750852dc04128e584f9= 3f8c5058 >=20 > Incorrect union member access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D9a5a7c90d5e5971fe2b9c9265e9279a6= f173a8f3 > CVE-2024-6119 FreeBSD-SA-24:13.openssl >=20 > Concurrent unsychronized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D1f5bf91a85e93afa17bc9c03fe7fade0= 852da046 >=20 > RAII > =3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D4b3141f5d5373989598f9447ab5a9f87= e2d1c9fb >=20 > Unchecked errors [^1] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D35f4984343229545881a324a00cdbb39= 80d675ce > = https://cgit.freebsd.org/src/commit/?id=3Deced2e2f1e56b54753702da52a88fccb= e73b3dcb > = https://cgit.freebsd.org/src/commit/?id=3Df625d038d2ae59fa1ae81b76079da464= ed6db61a >=20 > Not preventable by a safer programming language > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D7d6932d20aedbbb220cd78e90ab4e82d= 1abaad31 > = https://cgit.freebsd.org/src/commit/?id=3D6efba04df3f8c77b9b12f1df3e5124a7= 249b82fc > = https://cgit.freebsd.org/src/commit/?id=3D4b72bab96e8978eaed30fd44f7f51e1b= 4918d4db > = https://cgit.freebsd.org/src/commit/?id=3Db64afa41d56e98b5817aaf14c7deb0fa= 7e2142fb >=20 > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. >=20 --Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElMZjj3yN+bx0tQ6G3jmYZi1Z8hwFAmbaukwACgkQ3jmYZi1Z 8hzvHQ/+PJAXXKuTCOQiOsBCAS8ztPyYsItjrKKh8/R/vpW0Cclzp8XekkS806JY ES5wrnLdTFLc6m0mN20N+GYsmTZ6WpDRiprTYBamlcta6hL764/OuM+ro5Z3fBD5 aldM6eTVaVRzLILmEaLCwP9dElJw1J0K41W3em0thcUQETmri/+1kDLfS+G/qp+/ zb97W2ykeaaSjsJt6gZ7EAOlzVDuND7HM+atJ6mgPjbsOZrB2PC9S0HnWA39qIBc BrQNcTd6X4Mz0D7QeHHQxgQuoDa+8ao+RzP0zbAaeg4FB1aYfzdGUIpQd8hjJNqJ Zt9+NQjwS5s+4pBv4MBVzUxnG+jBwijbR4mcxFfNTGP1oq6ZVhe2j4teRSyo0OsU flITgTxb5La4Xrj810wRiqo0jMt75rRhAT8EB4BCSoTRQkiaeuwX4WqomSQ5uTes L+aim2YAN6xLYb1f+WXsAnSqlCK5xx2RpconYPsXyqThNaL90I3MZ7dAWeF29akU xPg7jUKB2lS1ID2x4vxJA3d61u7fXi+P6CBs6gis4UqnMAUCHY6LhdcGc99y+Io4 vCAIlxZq8zOO0uxOuF+lrBr2szsNZMfM27ry8dAWhDk3vTx1gkbwro6C6XhyV8o+ tFU1qu/546xX//BHXGS0DrbLDJPfCJGque27jZKl1ajxyUWW1zk= =CBTL -----END PGP SIGNATURE----- --Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC-- From nobody Fri Sep 6 08:25:13 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 4X0Tn80PHFz5WLC4 for ; Fri, 06 Sep 2024 08:25:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0Tn75zGbz4c9Q; Fri, 6 Sep 2024 08:25:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id AF4C88928B; Fri, 06 Sep 2024 08:25:13 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 4868PDWO042319; Fri, 6 Sep 2024 08:25:13 GMT (envelope-from phk) Message-Id: <202409060825.4868PDWO042319@critter.freebsd.dk> To: David Chisnall cc: Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> From: "Poul-Henning Kamp" References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> 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: text/plain; charset="UTF-8" Content-ID: <42317.1725611113.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 08:25:13 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X0Tn75zGbz4c9Q -------- David Chisnall writes: > On 6 Sep 2024, at 08:25, Poul-Henning Kamp wrote: > > > > I will also note that almost all the blame for C's current status > > lies with the standardization efforts, which almost seem hell-bent > > on destroying the language rather than improving it. > > As someone who is involved with C++ standardisation and so periodically = hears > things from WG14, my impression is that the people who care about the th= ings > that you list have all moved to C++, [=E2=80=A6] I've heard that from other sources too, strangely also from somebody quite active in the C standardization process, but no sane (to my mind) rationale was provided for this state of things. The C-stewardship situation has become increasingly intolerable to me, and I have practically already made up my mind, that Varnish Cache will migrate to a defined subset of C++, roughly corresponding to where I think C should have been by now. In one experiment, I wrapped the C-code in: #ifdef __cplusplus extern "C" { #endif and compiled it with a C++ compiler. Given that we have tried to dial code quality to 11 in Varnish, the number of relevant observations by the C++ compiler was a devastating indictment of how badly the C language has been let down by it's stewards. I'm not saying FreeBSD should think along the same lines, but FreeBSD should totally think along those same lines: Even if we stick with pure C-code, the C++ std-people have a much more sane approach to it's proper compilation that the C std-people. And there are nice features in C++ which do not make the source code unreadable. Poul-Henning -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Sep 6 08:36:42 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 4X0V2P3t2Gz5WMcF for ; Fri, 06 Sep 2024 08:36:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0V2P2xDCz4dcR; Fri, 6 Sep 2024 08:36:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 616F18928B; Fri, 06 Sep 2024 08:36:43 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 4868agnQ042462; Fri, 6 Sep 2024 08:36:42 GMT (envelope-from phk) Message-Id: <202409060836.4868agnQ042462@critter.freebsd.dk> To: Antranig Vartanian cc: Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: 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: text/plain; charset="us-ascii" Content-ID: <42460.1725611802.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 08:36:42 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X0V2P2xDCz4dcR -------- Antranig Vartanian writes: > My point is: yes, we do need better languages. Yes, we do need memory-sa= fety = > and better tooling. But is Rust the answer? Rust is what all the cool kids run right now, which they will deny, claiming that Rust Is Simply Superior in replies to this email, despite this prediction. But as I said in an email a couple of days ago: We should not anoint some particular subset of programming languages or other. We should answer the question "What is FreeBSD?" in a way which does not contain a very short and controversial list of "approved programming languages". A pkg-based FreeBSD will allow the Rust people to write good code for FreeBSD in Rust, and C, C++, Go, Lua, OBERON or Ada can freely compete with them, without causing year-long slug-fests on the mailing lists. And if the INTERCAL people want to write FreeBSD kernel code in INTERCAL, they get to maintain whatever it takes for their compiler to grok the interfaces to the kernel, likewise for any other language. Poul-Henning PS: I'm disappointed you did not mention Ada with SPARK. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Sep 6 08:52:35 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 4X0VNy00yDz5WPXS for ; Fri, 06 Sep 2024 08:52:50 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from fhigh3-smtp.messagingengine.com (fhigh3-smtp.messagingengine.com [103.168.172.154]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0VNx5HX2z4hCt; Fri, 6 Sep 2024 08:52:49 +0000 (UTC) (envelope-from antranigv@freebsd.am) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9CF96114015B; Fri, 6 Sep 2024 04:52:48 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Fri, 06 Sep 2024 04:52:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.am; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1725612768; x=1725699168; bh=HOqH/89thW qhhRoS+WbiWMyDuHSJJF784IKxhYAoy0g=; b=qr+UUgsr8Rfezsu+c0eOvDma7C vjFT5ughThuI02h9n3dMK7z3suiDxAzto+bMREodL1dRvCaeSKQJpITvS+0kp8uw fciBjTsvVTSQf+W6yrNtkYH7e6n1g9UAEsbNmr/6QQhQngFw13mX92BKKr5Jtm71 ncu8izbh7AX5wKs4bQtjNt2oEDSVcFxTnZLuE12xU12+BJI8GoGHXcYDiE9C1/TO MsFeFeo4yG5wEIDsiu8YkwSVGg/Z/wYA4i69FBfw/Z8QzzM4kB2ME09NuzBqhCwe dqTbPC34ktN3NfhhhSVSJFIkd+MQZMUH7okIjRpTUOi3u2X/2j+k0qw1dTxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725612768; x=1725699168; bh=HOqH/89thWqhhRoS+WbiWMyDuHSJ JF784IKxhYAoy0g=; b=H18U6xQerauNa6wmsOiOkb+vCHIEHatAe9aw01brh5Vk Hw+OMpvtdtFOfGnUxxzeogvgHlr7mnGShLTpa2TMiJDn0Hi9kU2I50pHpiHTMy6N IimQvWu88x+efp3YaudIEuDyLn6YUacwPQtkAsuyZpVDL/DaBkGw/FkgoOkmhwan b9JAITlW4/BnwUsAoHBx174MMxKLCeFbwmjRgqYIJ4YngOhzzqaeKfaPeauB+a3j f8ul8WN55F9j4gZsNK+xqWwY4lScgql9xbhYTYpl1K8QX65HT7KAIPN+D8T4y43O F2gVTC/0hsFTlJ1eq0qNC9NyExMY8UwbzX57EXVbyQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiuddgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptggguffhjgffvefkfhfvofesghdtmherhhdtjeen ucfhrhhomheptehnthhrrghnihhgucggrghrthgrnhhirghnuceorghnthhrrghnihhgvh esfhhrvggvsghsugdrrghmqeenucggtffrrghtthgvrhhnpeefgffhheekudeifffhgffh geffffetffevgfdtheeuveegleeihfdvheduudeiteenucffohhmrghinheprghnthhrrg hnihhgvhdrrghmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheprghnthhrrghnihhgvhesfhhrvggvsghsugdrrghmpdhnsggprhgtphhtthhope efpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehphhhksehphhhkrdhfrhgvvggs shgurdgukhdprhgtphhtthhopegrshhomhgvrhhssehfrhgvvggsshgurdhorhhgpdhrtg hpthhtohepfhhrvggvsghsugdqhhgrtghkvghrshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ibc494664:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Sep 2024 04:52:47 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_02CB27F2-F813-4037-80FC-4259B64F40A5"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) From: Antranig Vartanian In-Reply-To: <202409060836.4868agnQ042462@critter.freebsd.dk> Date: Fri, 6 Sep 2024 12:52:35 +0400 Cc: Alan Somers , FreeBSD Hackers Message-Id: References: <202409060836.4868agnQ042462@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4X0VNx5HX2z4hCt --Apple-Mail=_02CB27F2-F813-4037-80FC-4259B64F40A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 PHK, I=E2=80=99m sorry for disappointing, I should have indeed mentioned = SPARK ;) I totally agree with your =E2=80=9CWhat is FreeBSD?=E2=80=9D question, = and I would love to=20 compete using Oberon. Someone might need to say =E2=80=9CLet the games = begin=E2=80=9D. This is all the approval I need to start writing more Oberon code = specifically=20 for FreeBSD. We already have a Jail wrapper, libUCL wrapper, libxo = wrapper,=20 even ZFS wrapper that we use. And it=E2=80=99s been working very well = for us. Less bugs,=20 more productivity and easier debugging. So, ports? and maybe someday into PkgBase? Let=E2=80=99s see how it = goes. That=E2=80=99s all I needed from this mailing list. Kind regards, =E2=80=94 Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C > On 6 Sep 2024, at 12:36=E2=80=AFPM, Poul-Henning Kamp = wrote: >=20 > -------- > Antranig Vartanian writes: >=20 >> My point is: yes, we do need better languages. Yes, we do need = memory-safety=20 >> and better tooling. But is Rust the answer? >=20 > Rust is what all the cool kids run right now, which they will deny, > claiming that Rust Is Simply Superior in replies to this email, > despite this prediction. >=20 > But as I said in an email a couple of days ago: We should not > anoint some particular subset of programming languages or other. >=20 > We should answer the question "What is FreeBSD?" in a way which > does not contain a very short and controversial list of "approved > programming languages". >=20 > A pkg-based FreeBSD will allow the Rust people to write good code > for FreeBSD in Rust, and C, C++, Go, Lua, OBERON or Ada can freely > compete with them, without causing year-long slug-fests on the > mailing lists. >=20 > And if the INTERCAL people want to write FreeBSD kernel code in > INTERCAL, they get to maintain whatever it takes for their > compiler to grok the interfaces to the kernel, likewise for > any other language. >=20 > Poul-Henning >=20 >=20 > PS: I'm disappointed you did not mention Ada with SPARK. >=20 > --=20 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe =20 > Never attribute to malice what can adequately be explained by = incompetence. --Apple-Mail=_02CB27F2-F813-4037-80FC-4259B64F40A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElMZjj3yN+bx0tQ6G3jmYZi1Z8hwFAmbawtMACgkQ3jmYZi1Z 8hyMdQ/+JEo9atP/UsYvaGzL5sH7gs1LiBZay/OIb7uTPi4l1bdByOg044baBYuk zHZ8Jc47lCKbGTuxQa/AMnrXddIn9P6VRuBmpw2WTax1mT89H3uzD/iqNeQKUUDX jOZJ1alq10PoPbG8On4mlEgxJ5UQ0VePC0p3Itb5tQU9fW9/lLpmlm6CJOGDBd2n brheZA+dNdVtmVvXDiEjhALz5bF1bSOZinRM7tb4EGY22Frm4rXGbTrO4yv/W4sL /dxOXCZCWCcg9Dtf40J+uThVUNHi6c4V0J+E2rjOQshZ9AAmjWKLaVQuS0y1+ogt wshVfgHHHf1/4ZQyD3BRY5HXKrdRbHaGM12lHS9II6gdUGeaGlL49jVfrceBLeS9 v70w+E8jaYgj8K92qNwkI04q7bPt5chesb6DVSYEp8mJcYB5ZIFmIXjP3TuNFBbI Ya3qcFh1txHNKjRGPAUaweurI8pS/0jAj66o1CfHeE3nTa4ZkJr/rEskm3V5+NbI 8zazHhfFMMPUe8F90DwLsBNIILvmZBvWi4b9og3G6oj4lCQC3vzA6xE5c/5HOShm Lyxb/tfVTcqntAyvatzJt1K+dDqv6TBJPHQjWBTUnu0Y1JFPzKDoMovaTrm0gXlz QCsc4RsEb+3jTNuh/UYqB3Wuky1PkjNnJOb+RFIHgEytZhaDmBo= =Cb+5 -----END PGP SIGNATURE----- --Apple-Mail=_02CB27F2-F813-4037-80FC-4259B64F40A5-- From nobody Fri Sep 6 09:29:20 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 4X0WC56gCmz5WTBt for ; Fri, 06 Sep 2024 09:29:21 +0000 (UTC) (envelope-from bapt@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 4X0WC56497z4mvp; Fri, 6 Sep 2024 09:29:21 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725614961; 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=Ktw/hE/s58UQU9fQynPuCEbiL4q4+osCuDbAfIP/NQc=; b=UphaF86iapgsgF6T6GkSjeu188tZ6TJ2mY6kYeX9MWBItX9KNDpHOWX+1rTNKzUzKv8iJD OAJyZOW+0L9UGIFS2Tki2FxUHt+XtaND4nJC2S9cQTXZWGvDsx/g83raktNk+4pVQSDryg O9S7pknOQNez8NDChSdOVFftlp9B8u0Mu/yRNZiiE85BuciwQZrLPAe3YT041ZSNoQsSao 9iUY4tYj6lJtl77JCbuOC+uCmObRnMQZl/6YacozbG4aSpBgJdfwF5f1HU7u7z2is9b6es mb9WL8F5J0E0Q8LcWoX8ZxYNpbFcDrrJziSOL9+9KHDnUfwEpmb81dBn8YzFlw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725614961; a=rsa-sha256; cv=none; b=f9wb1nc2Y85GCnLP3ikIinCW7I9B6A8+PixtMHD++1SBJ9FIIWVqb98ct0gx6Kghe3QrAr SeuP8BDSkKLjDNpIv8WuCgtRMdxs1KQ3qEVHPTrizPY0RQlqhMAQBQSfIejRDnAskWKEBg B9BSn99ZlUo7FO+Yc4ZLrHHMcuvIR+CFO6L2mat12W02Zyoh0B6rtQkiu0AYEmKkAs6L6L Z25FiC76KB/CeGVQRAdkJFCSuCmsolzjRPKFKHi1Ita/QVjIsox1yYpBTw+TMOruH6TsLh f0H4Zd3fytMTOrm900D69QC5DP8FVKN6j2FJWZyryISYP9NXza3T5+YM5cfuHA== 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=1725614961; 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=Ktw/hE/s58UQU9fQynPuCEbiL4q4+osCuDbAfIP/NQc=; b=WoZhuhNcSg2pG0XGIAb5s9kvVARghrYOmjr0nyVhSrXPXy5ec70VD+TU83Sy/i6/UZjE0Q gQr2jVGZTNO3xg3R6tp3fHDIa1ggAGeg61L6CoaDXd7X3UDhWuOm+Vq63Nay35LuN7kkXd BVtTaeIn5Pir3VgAPahIcRQRfdylS7YlEsfjRwBQIHQs6QufQFp659jKEKm8f24xCk7J71 h6jVV/qkgrQWd/7PN9BCI1MU8+k4VdtB2w/D//HTeQL/mivXLYB6RfxtoMy30tHrVQiNmh cBQnGBxakjrT7FQPvASfJ+VlreUtaSETKXuDbDjsx7rHagQbVrYtDRDdRTUnIw== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (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: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0WC54xgnzKLv; Fri, 6 Sep 2024 09:29:21 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 7361D23B6AA; Fri, 6 Sep 2024 11:29:20 +0200 (CEST) Date: Fri, 6 Sep 2024 11:29:20 +0200 From: Baptiste Daroussin To: Mark Johnston Cc: freebsd-hackers@freebsd.org, kevans@freebsd.org, imp@freebsd.org Subject: Re: adding new flua libraries Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu 05 Sep 18:51, Mark Johnston wrote: > FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's > intended for use by the base system, and so far has a few consumers, but > not many so far. (As an aside, flua's intended scope is not totally > clear to me. Is it only for use by the base system? What compatibility > guarantees does it provide, if any?) > > A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > available, but they don't provide enough to make flua useful as a > general purpose programming tool. It lacks interfaces for interacting > with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > standard programming facilities (e.g., classes, higher-order functions, > etc.). Here I'm mostly interested in discussing the former. > > I think flua could be a very useful alternative to shell scripts and C > code where performance is not critical. It's very good at wrapping C > interfaces and thus could be used to make FreeBSD features (jails, > bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > don't want to interact with C. > > It's a lot of work to build up a set of flua modules that provide enough > functionality to be generally useful. My feeling is that the easiest > way to get there is to wrap C interfaces directly (to the extent that > that's possible, but it's usually easy) and expose them in flua as a > stable interface. Libraries written in pure Lua (or other languages > that interoperate well with Lua) could be built on top of that. > > I'm inclined to start by wrapping libc and libsys interfaces in a manner > similar to luaposix. There, the namespace is partitioned by C headers, > so posix.unistd contains identifiers from unistd.h, posix.sys.stat > contains identifiers from sys/stat.h, and so on. In fact, flua already > has a small subset of luaposix's functionality. Wrapping C interfaces > isn't much fun, but it's easy, and it saves us having to come up with > names and interfaces (naming things is hard), and helps ensure that the > glue code is relatively small and doesn't impose a large testing burden. > Moreover, C interfaces don't change much and are subject to > well-understood compatibility constraints, which should mean that Lua > interfaces built on top of them are subject to the same constraints. > > Assuming there's general agreement on that approach, the question I'd > really like to answer is, what should the namespace look like? It would > be useful to provide a posix module compatible with luaposix, but that > obviously won't contain FreeBSD-specific functionality. > > I propose having a top-level "freebsd" namespace for all modules > implemented in the base system, excluding posix and contrib libraries > which already define a Lua interface (libucl is the one example I see so > far; we could import sqlite bindings as well). Then, if we follow > luaposix's convention, we could have freebsd.sys.capsicum.* for > Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent > wrappers, and so on. The posix module could simply provide a subset of > freebsd.*. > > Maybe it's better to separate C wrappers from native Lua modules though, > so it could be better to have freebsd.c.sys.capsicum.*, etc., and > provide higher-level interfaces for FreeBSD features under freebsd.pf, > freebsd.zfs, freebsd.jail, etc.. I'm not really sure. > > In the interest of prompting discussion a bit, I posted some patches to > add some example wrappers to flua: > https://reviews.freebsd.org/D46553 > https://reviews.freebsd.org/D46554 > https://reviews.freebsd.org/D46556 > > Does anyone have opinions on anything I've brought up above? I'm pretty > happy to write a lot of this glue code or find ways to automate it, as > I've already done a fair bit of it, but it's hard to make progress > without having some rigourous conventions for the flua namespace (again, > naming things is hard). I like all of what I read and I am fully aligned. What I don't see here, is I think we should have dynamic modules libucl, fbsd & friends are not dynamic and the reviews I see for the freebsd module reviews, this is still bundled. my proposal for unbundling, I need kldload for a project of mine, so I did: https://reviews.freebsd.org/D46558 Best regards, Bapt From nobody Fri Sep 6 13:15:45 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 4X0cDM2xqDz5V2XL for ; Fri, 06 Sep 2024 13:15:47 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X0cDL6YL3z4Fjn for ; Fri, 6 Sep 2024 13:15:46 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 35542 invoked by uid 89); 6 Sep 2024 13:15:45 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 6 Sep 2024 13:15:45 -0000 Content-Type: multipart/alternative; boundary="------------SAXOS04t0oRybAieYmCfmxlX" Message-ID: <1dcfee7b-11e7-4bde-aa5f-6d90101a6022@digitaldaemon.com> Date: Fri, 6 Sep 2024 09:15:45 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: David Chisnall , Alan Somers Cc: Dmitry Salychev , freebsd-hackers@freebsd.org References: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X0cDL6YL3z4Fjn This is a multi-part message in MIME format. --------------SAXOS04t0oRybAieYmCfmxlX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/6/24 03:02, David Chisnall wrote: > On 5 Sep 2024, at 22:13, Alan Somers wrote: >> I used to check it, years ago. But I gave up. The UI is too hard to >> use and false alarms are both too frequent and too hard to suppress. >> Plus, it's a real drag that I can't run the tool myself. Instead, I >> need to wait for the next scheduled run. > In general, it’s very hard to add static analysis to existing projects. Not the experience I have. It was as simple as wrapping the build with 'cov-'. (Also, Coverity would come and visit us, and assist with setting up and getting analyzes started). > The property that you want is that there are no *new* static analyser errors in a new commit, but that’s requires tracking all of the existing ones. Coverity, when we used it did keep track of all the issues: A false positive, when marked as false, would not be reported again. A true positive, thus an actual problem, most (all!) of the time would disappear after the code was fixed and Coverity was run again. Every analyzer I have ever used gives false positives. VeraCode was one of the worst. Coverity was one of the best. (But times have changed) > In CHERIoT RTOS, we run the clang analyser in CI as one of the checks that must pass before a PR can be merged. This is possible because we started doing it very early on. Good! :-) > It may be possible for some individual parts of FreeBSD, but when we started with Coverity I looked at the reports and the first ten I looked at were all false positives. That can happen. I think when we first started with Coverity the false positives where just less then 50%. Which is truly extremely good for an analyzer. Then Coverity was tuned/reconfigured a bit and it became much better. > There are probably some serious issues in there but the effort to find them is high. For a new project, that cost is a small incremental cost in each commit and code review (if the analyser finds something, reviewer has to agree that it’s a false positive). > Well, the cost is high on an existing project alike FreeBSD, because this has not been done... My guess is... It could be considered 'Technical Debt'. What helps quite a bit is tuning Coverity to the right configuration, so the false positives are not overwhelming. Then, when the true positives are resolved, dial the tuning back a little. Jan --------------SAXOS04t0oRybAieYmCfmxlX Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/6/24 03:02, David Chisnall wrote:
On 5 Sep 2024, at 22:13, Alan Somers <asomers@freebsd.org> wrote:

I used to check it, years ago.  But I gave up.  The UI is too hard to
use and false alarms are both too frequent and too hard to suppress.
Plus, it's a real drag that I can't run the tool myself.  Instead, I
need to wait for the next scheduled run.

In general, it’s very hard to add static analysis to existing projects.
Not the experience I have.
It was as simple as wrapping the build with 'cov-<something>'.
(Also, Coverity would come and visit us, and assist with setting up and getting analyzes started).
 The property that you want is that there are no *new* static analyser errors in a new commit, but that’s requires tracking all of the existing ones.
Coverity, when we used it did keep track of all the issues:
A false positive, when marked as false, would not be reported again.
A true positive, thus an actual problem, most (all!) of the time would disappear after the code was fixed and Coverity was run again.

Every analyzer I have ever used gives false positives.
VeraCode was one of the worst.
Coverity was one of the best.
(But times have changed)
 In CHERIoT RTOS, we run the clang analyser in CI as one of the checks that must pass before a PR can be merged. This is possible because we started doing it very early on.
Good! :-)
 It may be possible for some individual parts of FreeBSD, but when we started with Coverity I looked at the reports and the first ten I looked at were all false positives.
That can happen. I think when we first started with Coverity the false positives where just less then 50%. Which is truly extremely good for an analyzer. Then Coverity was tuned/reconfigured a bit and it became much better.
 There are probably some serious issues in there but the effort to find them is high. For a new project, that cost is a small incremental cost in each commit and code review (if the analyser finds something, reviewer has to agree that it’s a false positive).
Well, the cost is high on an existing project alike FreeBSD, because this has not been done... My guess is... It could be considered 'Technical Debt'.
What helps quite a bit is tuning Coverity to the right configuration, so the false positives are not overwhelming. Then, when the true positives are resolved, dial the tuning back a little.

Jan


--------------SAXOS04t0oRybAieYmCfmxlX-- From nobody Fri Sep 6 13:16: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 4X0cFV06pMz5V2qN for ; Fri, 06 Sep 2024 13:16:46 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0cFT42nnz4GQf; Fri, 6 Sep 2024 13:16:45 +0000 (UTC) (envelope-from eischen@vigrid.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (mobile-166-196-106-050.mycingular.net [166.196.106.50] (may be forged)) (authenticated bits=0) by mail.netplex.net (8.18.1/8.15.1/NETPLEX) with ESMTPSA id 486DGa6H060878 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Sep 2024 09:16:36 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 06 Sep 2024 09:16:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Daniel Eischen 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 09:16:26 -0400 Message-Id: <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> References: <202409060836.4868agnQ042462@critter.freebsd.dk> Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers In-Reply-To: <202409060836.4868agnQ042462@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPhone Mail (21G93) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] X-Rspamd-Queue-Id: 4X0cFT42nnz4GQf > On Sep 6, 2024, at 4:37=E2=80=AFAM, Poul-Henning Kamp = wrote: >=20 > =EF=BB=BF-------- > Antranig Vartanian writes: >=20 >> My point is: yes, we do need better languages. Yes, we do need memory-saf= ety >> and better tooling. But is Rust the answer? >=20 > Rust is what all the cool kids run right now, which they will deny, > claiming that Rust Is Simply Superior in replies to this email, > despite this prediction. >=20 > But as I said in an email a couple of days ago: We should not > anoint some particular subset of programming languages or other. >=20 > We should answer the question "What is FreeBSD?" in a way which > does not contain a very short and controversial list of "approved > programming languages". >=20 > A pkg-based FreeBSD will allow the Rust people to write good code > for FreeBSD in Rust, and C, C++, Go, Lua, OBERON or Ada can freely > compete with them, without causing year-long slug-fests on the > mailing lists. >=20 > And if the INTERCAL people want to write FreeBSD kernel code in > INTERCAL, they get to maintain whatever it takes for their > compiler to grok the interfaces to the kernel, likewise for > any other language. >=20 > Poul-Henning >=20 >=20 > PS: I'm disappointed you did not mention Ada with SPARK. +1 And back in the 80s, Ada was supposed to be the answer for safe coding langu= age. -- DE= From nobody Fri Sep 6 13:20:06 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 4X0cKN1M6Bz5V34c for ; Fri, 06 Sep 2024 13:20:08 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X0cKM6lkwz4HPn for ; Fri, 6 Sep 2024 13:20:07 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 36176 invoked by uid 89); 6 Sep 2024 13:20:07 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 6 Sep 2024 13:20:07 -0000 Content-Type: multipart/alternative; boundary="------------pFGvu7x3n00KwKyCXnuP6kOy" Message-ID: Date: Fri, 6 Sep 2024 09:20:06 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: David Chisnall , Poul-Henning Kamp Cc: Alan Somers , Dmitry Salychev , freebsd-hackers@freebsd.org References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X0cKM6lkwz4HPn This is a multi-part message in MIME format. --------------pFGvu7x3n00KwKyCXnuP6kOy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Second this. (Not involved with C++ standardization, but closely follow it.) On 9/6/24 03:41, David Chisnall wrote: > On 6 Sep 2024, at 08:25, Poul-Henning Kamp wrote: >> I will also note that almost all the blame for C's current status >> lies with the standardization efforts, which almost seem hell-bent >> on destroying the language rather than improving it. > As someone who is involved with C++ standardisation and so periodically hears things from WG14, my impression is that the people who care about the things that you list have all moved to C++, where they were solved problems at least a decade ago. The people still actively driving C are the people who didn’t leave because they don’t want these things (and, increasingly, C++ people who just want to make sure that C doesn’t diverge too much from being a subset of C++). > > It’s trivial to write a packed struct in C++ where the fields are all BigEndian that do byte swapping on implicit conversion to and from T, for example. Integer ranges can be implemented in the same way and there is a proposal to add them to the standard library that looks nice (the ranged integers are a small part, the proposal is mostly about units and quantities). > > Having written a kernel in C++, and worked on two in C, and read a reasonable amount of one written in Rust, I am firmly of the opinion that C is absolutely the worst choice for writing a kernel. This was not true in the ‘80s and it wasn’t true even 15-20 years ago, so the question is how to move from where we are to where we should be. The strategy document that I coauthored at Microsoft recommended the following: > > - C++ conforming to the Core Guidelines and with static analysis for existing C/C++ projects with the C parts incrementally migrated to C++. > - Rust, C#, or TypeScript for new projects and discrete new components with well-defined interface boundaries. > - No new C code, except in open-source projects that accept only C contributions. > > That’s probably not quite the right shape for FreeBSD (at the very least, I’d recommend Lua instead of C# or TypeScript in most places). > Jan --------------pFGvu7x3n00KwKyCXnuP6kOy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Second this.

(Not involved with C++ standardization, but closely follow it.)

On 9/6/24 03:41, David Chisnall wrote:
On 6 Sep 2024, at 08:25, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

I will also note that almost all the blame for C's current status
lies with the standardization efforts, which almost seem hell-bent
on destroying the language rather than improving it.

As someone who is involved with C++ standardisation and so periodically hears things from WG14, my impression is that the people who care about the things that you list have all moved to C++, where they were solved problems at least a decade ago. The people still actively driving C are the people who didn’t leave because they don’t want these things (and, increasingly, C++ people who just want to make sure that C doesn’t diverge too much from being a subset of C++).

It’s trivial to write a packed struct in C++ where the fields are all BigEndian<T> that do byte swapping on implicit conversion to and from T, for example. Integer ranges can be implemented in the same way and there is a proposal to add them to the standard library that looks nice (the ranged integers are a small part, the proposal is mostly about units and quantities).

Having written a kernel in C++, and worked on two in C, and read a reasonable amount of one written in Rust, I am firmly of the opinion that C is absolutely the worst choice for writing a kernel. This was not true in the ‘80s and it wasn’t true even 15-20 years ago, so the question is how to move from where we are to where we should be. The strategy document that I coauthored at Microsoft recommended the following:

 - C++ conforming to the Core Guidelines and with static analysis for existing C/C++ projects with the C parts incrementally migrated to C++.
 - Rust, C#, or TypeScript for new projects and discrete new components with well-defined interface boundaries.
 - No new C code, except in open-source projects that accept only C contributions.

That’s probably not quite the right shape for FreeBSD (at the very least, I’d recommend Lua instead of C# or TypeScript in most places).

Jan

--------------pFGvu7x3n00KwKyCXnuP6kOy-- From nobody Fri Sep 6 13:24:34 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 4X0cQX2Fstz5V3Xg for ; Fri, 06 Sep 2024 13:24:36 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X0cQX0Xzwz4Jxh for ; Fri, 6 Sep 2024 13:24:36 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 36742 invoked by uid 89); 6 Sep 2024 13:24:35 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 6 Sep 2024 13:24:35 -0000 Content-Type: multipart/alternative; boundary="------------PysUyqlcn00h7wlpA7Bl3Qqg" Message-ID: Date: Fri, 6 Sep 2024 09:24:34 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Poul-Henning Kamp , David Chisnall Cc: Alan Somers , Dmitry Salychev , freebsd-hackers@freebsd.org References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> <202409060825.4868PDWO042319@critter.freebsd.dk> Content-Language: en-US From: Jan Knepper In-Reply-To: <202409060825.4868PDWO042319@critter.freebsd.dk> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X0cQX0Xzwz4Jxh This is a multi-part message in MIME format. --------------PysUyqlcn00h7wlpA7Bl3Qqg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/6/24 04:25, Poul-Henning Kamp wrote: > -------- > David Chisnall writes: >> On 6 Sep 2024, at 08:25, Poul-Henning Kamp wrote: >>> I will also note that almost all the blame for C's current status >>> lies with the standardization efforts, which almost seem hell-bent >>> on destroying the language rather than improving it. >> As someone who is involved with C++ standardisation and so periodically hears >> things from WG14, my impression is that the people who care about the things >> that you list have all moved to C++, […] > ... > In one experiment, I wrapped the C-code in: > > #ifdef __cplusplus > extern "C" { > #endif > > and compiled it with a C++ compiler. > > Given that we have tried to dial code quality to 11 in Varnish, the > number of relevant observations by the C++ compiler was a devastating > indictment of how badly the C language has been let down by it's > stewards. > > I'm not saying FreeBSD should think along the same lines, but FreeBSD > should totally think along those same lines: > > Even if we stick with pure C-code, the C++ std-people have a much > more sane approach to it's proper compilation that the C std-people. > > And there are nice features in C++ which do not make the source code > unreadable. > Second this. Not surprised... I have done this as long as C++ as been around and it always made for better code in the end. Truly, this is one of the easy things that could be done with FreeBSD code, and probably would help quite a bit improving the code. Jan --------------PysUyqlcn00h7wlpA7Bl3Qqg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/6/24 04:25, Poul-Henning Kamp wrote:
--------
David Chisnall writes:

On 6 Sep 2024, at 08:25, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

I will also note that almost all the blame for C's current status
lies with the standardization efforts, which almost seem hell-bent
on destroying the language rather than improving it.

As someone who is involved with C++ standardisation and so periodically hears
things from WG14, my impression is that the people who care about the things
that you list have all moved to C++, […]

...
In one experiment, I wrapped the C-code in:

	#ifdef __cplusplus
	extern "C" {
	#endif

and compiled it with a C++ compiler.

Given that we have tried to dial code quality to 11 in Varnish, the
number of relevant observations by the C++ compiler was a devastating
indictment of how badly the C language has been let down by it's
stewards.

I'm not saying FreeBSD should think along the same lines, but FreeBSD
should totally think along those same lines:

Even if we stick with pure C-code, the C++ std-people have a much
more sane approach to it's proper compilation that the C std-people.

And there are nice features in C++ which do not make the source code
unreadable.
Second this.

Not surprised...

I have done this as long as C++ as been around and it always made for better code in the end.

Truly, this is one of the easy things that could be done with FreeBSD code, and probably would help quite a bit improving the code.

Jan

--------------PysUyqlcn00h7wlpA7Bl3Qqg-- From nobody Fri Sep 6 14:24:07 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 4X0dlS3cjHz5V9wX for ; Fri, 06 Sep 2024 14:24:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0dlS1X3Zz4S4d for ; Fri, 6 Sep 2024 14:24:20 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-846bc75136eso521455241.3 for ; Fri, 06 Sep 2024 07:24:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725632659; x=1726237459; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ihU1IY6TB9MF30F06ZebofAOjXbQOKOJ83fRkWKf/H0=; b=qP9HIwXh1Zsuwk0vijxKYwuhyAXupLn2ySNYGayW/aOtb+gCBatYJhlbrx4i73aq4n SidFOU4n8/476R+pLMB2d7KLwqJbtSlspItKvYnwaPuIBlnpeWok11MY2a5x85zef8dR 8LUiCZrfRbA3O0Uil/GUoIbvxqSRVcGzqUOiAW0DYwtW9ow9X2o5tO7eZuWU42Hk4V50 ng539Rq4qOrA1oDRfU1UmzMLzW+Ol+Thi/qcn5Y59Vq9pQpFH+PjAzFXZMVrKVH9494J JT/EJYjXKaQRBd2HfxDhWAGUjm0abNw8/yKnU3TAGIPV34hPuotZR/yOS7zosnfZF0B1 v/Zw== X-Forwarded-Encrypted: i=1; AJvYcCWmmzA+7V3tUjT+ICUN5aHCDyHy7LHJNM3pRWFjqojxX7E8HitmY5vpXAUTxB5IQhlM7/IdylEC/1PN3apz/N0=@freebsd.org X-Gm-Message-State: AOJu0YwRCNgNU0KtdWup1HurazSM9LEtVq0qMwlO7TU4Gk0rtxhjxMwg pIma7gcuW7/AwwrdsKF0zxomsUv5aaiuWuGVa8Dcy9XeH5LkEQbcYTMsjeAHwcYgkei07ErExPV ULagMBEUip/cvWo4UGKKRErn8314dyg== X-Google-Smtp-Source: AGHT+IH094NsJg6bRzYfjt7wok9JLIVK/npcBPmkF6DsVUUQhZ2i/d5t40EwrQWlxEO5HsngXEuRsHhhR118P+0U1E8= X-Received: by 2002:a05:6122:2a12:b0:4eb:499a:2453 with SMTP id 71dfb90a1353d-502143ca0bamr3006671e0c.8.1725632658940; Fri, 06 Sep 2024 07:24:18 -0700 (PDT) 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 References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> In-Reply-To: <20240905225129.UvYYMXDa@steffen%sdaoden.eu> From: Alan Somers Date: Fri, 6 Sep 2024 08:24:07 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Steffen Nurpmeso Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X0dlS1X3Zz4S4d On Thu, Sep 5, 2024 at 4:51=E2=80=AFPM Steffen Nurpmeso wrote: > > sigh. now i am back. > > ske-89@pkmab.se wrote in > <202409052313.aa18097@berenice.pkmab.se>: > |Alan Somers wrote: > |> In fact, of all the C bug fixes that I've been involved with (as > |> either author or reviewer) since May, about three quarters could've > |> been avoided just by using a better language. > |... > |> To summarize, here's the list of this week's security advisories, and > |> also some other recent C bug fixes of my own involvement: > | > |After checking several of these examples, I'm wondering what the code > |would have looked like in some "better language", where those bugs woul= d > |have been avoided? > > Examples. I find the absolute opposite after checking four. > Ie, if you implement some SCSI command > > - > - /* > - * struct scsi_sense_data, which is currently set to 256 bytes, i= s > - * larger than the largest allowed value for the length field in = the > - * REQUEST SENSE CDB, which is 252 bytes as of SPC-4. > - */ > - ctsio->kern_data_len =3D cdb->length; > - ctsio->kern_total_len =3D cdb->length; > + ctsio->kern_data_len =3D ctsio->kern_total_len =3D > + MIN(cdb->length, sizeof(*sense_ptr)); > > This is a super clear logic error, that even says the comment, > which did not care for security related impacts. It came in as > part of a tremendious super large patch "Add the CAM Target Layer > (CTL)." (130f4520cba830cc6da47c9f871fed78710a4709) in 2012, 34000 > lines of code additions. There were a couple of fixup commits. > It seems to have been sponsored, but i have no idea of review or > anything. Compared to the WireGuard stuff, for example. > Now i had to look more deeply why the commit says three bytes > whereas the naive eye counts four. (Maybe NUL terminated.) > > The ones from OpenSSL and ctld are more complex. But the libnv is > pretty clear again, it even uses strnlen() (urgh). > > |E.g for the "use after free" or "unitialized memory" examples. > > Examples. You are just saying. > > |To me, several of those bugs seem fairly complex, and not just a > |question of having bounds checking for arrays or a borrow checker > |for pointers, or something simple like that. > > Two of four. > > |But maybe the bugs could have been detected[.] > > yes, maybe. I doubt it. > > |[.] and prevented if the > |code would have been forced to be expressed in a completely > |different manner by some other language? Or what is your vision > |of how that would be accomplished? > > Actually yes. String objects. > I mean it is easy to say that, but if you look at the SCSI thing, > one would normally do things like eg > > we_parse_THIS_SCSI_COMMAND([.]u8 *buf, u16 len){ > ... > /* C99 */{ > struct a_mmc_cmd_x42_resp_data_head *dhp; > > ^argument etc of THIS_SCSI_COMMAND > > dhp =3D R(struct a_mmc_cmd_x42_resp_data_head*,buf); > buf +=3D sizeof(*dhp); > len -=3D sizeof(*dhp); > } > ... > irp =3D R(struct a_mmc_cmd_x42_isrc_resp*,buf); > > Unfortunately it was forgotten for one of many use cases, where > a byte buffer of reality matches a structure of a language > abstraction. How could a different language aid here. > > |You seem to be saying that certain examples would be solved by > |a better language, and certain ones would not, so I suppose you > |do have some vision of how that would work. > > And *i* am saying that for example the nvlist could have been done > very safely in C, if instead of strnlen() etc something more sane > would have been used. Like a string object. But it is more > typing work etc. *That* of course, yes. > > |I'm just curious to learn more, since it is not obvious to me, > |and thus all the more interresting. > > This is all very unspecific. I have also seen quite a lot of > things. What should be the answer to this unspecific question, > except continuation of this thread? I'm having trouble following your English, but you seem to be missing the point. The point is not whether the bugs can be fixed in C; of course they can, after all we just did. The point is that safe programming languages make it nearly impossible to create the bugs in the first place. For example, a language that uses RAII everywhere makes it nearly impossible to allocate a structure without initializing it. Nearly impossible to leak memory, too. > > |/Kristoffer Eriksson > --End of <202409052313.aa18097@berenice.pkmab.se> > > In support for that swedish hm virgin, yes, sweden is not a clean > country for sure. Again, I don't know what you mean. But it looks like a personal attack to me. Please try to keep your discourse on the public mailing lists respectful. -Alan From nobody Fri Sep 6 14:45:19 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 4X0fCj39qVz5VDCh for ; Fri, 06 Sep 2024 14:45:21 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0fCj2dqfz4Yjy; Fri, 6 Sep 2024 14:45:21 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725633921; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eEkjQll565wQpo0vv6qNew24tL3Y6z8htGYkZxk7yqA=; b=MQgfmqDssFODPVlIO8aiiqDoDfALlznzeqNlmNH4ccA07s4mAOR/sVBn2qDNBtJwLTHrg8 c48lzPhP5M+j+ZbD9ZTe4tWKeYscBI5GTlvzs6j+m1NGJoQaxrtJc4at04xnaGXwA/O7dc J46cZz7OppSmOnxsmK5NgU7JHoIwV10SE4QkGcIDIhLkrB/sOkYBqWoz5VFP9h/pxkHp5b wO4mlvnW8HhYLvJrY2YpFor6C0qI4rxsBayc50GQeHuyQ0N6WFpfBrBNL74ympnKDellgh qh3D311fTf+e8DzqgVWLsNS6NpgvKKwkR83EO3+7+5lhYt1D1Z9Nxyoxbmcv7A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725633921; a=rsa-sha256; cv=none; b=PUR5jjYO3aEwVxeqI9WQarnnMA4GNHjIannM/VyX7pqGQQPwb7tpbRuvggBjVpVGOh67aF 36xdUEccULsB/YQOOC+ILxbec0Zgdw1dCbteU3AtpQQgV+ur7hiXnuKGJZFlUnr21UNoDu ak0OxHQXJaSF+/GqZyzafywEhVXPA8TRnpcFkRFCuNJ4UNj3XiaKPUByNrSbxN1z8sq3Me ipSdggOmcLgJ2BgLTxN6tREkTQhBn6LzzuG+HrxdDNwaYdigH3HhDjJN8IiiBzP9tORm2n x+1j3jF7VXubLZDMB4L+Tdv7HZSr56LFWDOOeO/6I8XPRjH81/4zwEFmD/XZqg== 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=1725633921; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eEkjQll565wQpo0vv6qNew24tL3Y6z8htGYkZxk7yqA=; b=yDBRmWH/yo7cQVY8JgUzUmOD9ZQKYOvH0JQXLKZxe0hCPiEnU8AzcZUCTJK5ZV1nJDLMF6 C5hYSEP/6lbyNZ8lgTFbr+BDh+T5Znq1XFjlvV2Tf+lVtDDV4dpsuwtPLG4FSxx5XNG71E 5zso871d6pDs/S/zKqINq4gUMjFyJHWmlQdYICxcmVfpaSs2bRL58h5zCMEKho/891dLxA UogB6RpbQwwl8jvCVx7F9OyQ2wQgSPeg8Fe50rM6twCUocB82ITbh/bUFR5rZD3MGxfeE1 WGDq0QsqZ4c1vd2v6jTe1J9gaXOflRCJkXC3PQaPVWrO1jiv77k2DLZenAfPRA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0fCh6TZ0zRmg; Fri, 6 Sep 2024 14:45:20 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <2f3039bc-883c-4b11-ab20-d1873c6cc555@FreeBSD.org> Date: Fri, 6 Sep 2024 09:45:19 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: adding new flua libraries To: Baptiste Daroussin , Mark Johnston Cc: freebsd-hackers@freebsd.org, imp@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/6/24 04:29, Baptiste Daroussin wrote: > On Thu 05 Sep 18:51, Mark Johnston wrote: >> FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's >> intended for use by the base system, and so far has a few consumers, but >> not many so far. (As an aside, flua's intended scope is not totally >> clear to me. Is it only for use by the base system? What compatibility >> guarantees does it provide, if any?) >> >> A few flua modules wrapping FreeBSD libraries (e.g., libjail) are >> available, but they don't provide enough to make flua useful as a >> general purpose programming tool. It lacks interfaces for interacting >> with the system (e.g., libc/libsys/libutil/etc wrappers) as well as >> standard programming facilities (e.g., classes, higher-order functions, >> etc.). Here I'm mostly interested in discussing the former. >> >> I think flua could be a very useful alternative to shell scripts and C >> code where performance is not critical. It's very good at wrapping C >> interfaces and thus could be used to make FreeBSD features (jails, >> bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who >> don't want to interact with C. >> >> It's a lot of work to build up a set of flua modules that provide enough >> functionality to be generally useful. My feeling is that the easiest >> way to get there is to wrap C interfaces directly (to the extent that >> that's possible, but it's usually easy) and expose them in flua as a >> stable interface. Libraries written in pure Lua (or other languages >> that interoperate well with Lua) could be built on top of that. >> >> I'm inclined to start by wrapping libc and libsys interfaces in a manner >> similar to luaposix. There, the namespace is partitioned by C headers, >> so posix.unistd contains identifiers from unistd.h, posix.sys.stat >> contains identifiers from sys/stat.h, and so on. In fact, flua already >> has a small subset of luaposix's functionality. Wrapping C interfaces >> isn't much fun, but it's easy, and it saves us having to come up with >> names and interfaces (naming things is hard), and helps ensure that the >> glue code is relatively small and doesn't impose a large testing burden. >> Moreover, C interfaces don't change much and are subject to >> well-understood compatibility constraints, which should mean that Lua >> interfaces built on top of them are subject to the same constraints. >> >> Assuming there's general agreement on that approach, the question I'd >> really like to answer is, what should the namespace look like? It would >> be useful to provide a posix module compatible with luaposix, but that >> obviously won't contain FreeBSD-specific functionality. >> >> I propose having a top-level "freebsd" namespace for all modules >> implemented in the base system, excluding posix and contrib libraries >> which already define a Lua interface (libucl is the one example I see so >> far; we could import sqlite bindings as well). Then, if we follow >> luaposix's convention, we could have freebsd.sys.capsicum.* for >> Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent >> wrappers, and so on. The posix module could simply provide a subset of >> freebsd.*. >> >> Maybe it's better to separate C wrappers from native Lua modules though, >> so it could be better to have freebsd.c.sys.capsicum.*, etc., and >> provide higher-level interfaces for FreeBSD features under freebsd.pf, >> freebsd.zfs, freebsd.jail, etc.. I'm not really sure. >> >> In the interest of prompting discussion a bit, I posted some patches to >> add some example wrappers to flua: >> https://reviews.freebsd.org/D46553 >> https://reviews.freebsd.org/D46554 >> https://reviews.freebsd.org/D46556 >> >> Does anyone have opinions on anything I've brought up above? I'm pretty >> happy to write a lot of this glue code or find ways to automate it, as >> I've already done a fair bit of it, but it's hard to make progress >> without having some rigourous conventions for the flua namespace (again, >> naming things is hard). > > I like all of what I read and I am fully aligned. > > What I don't see here, is I think we should have dynamic modules libucl, fbsd & > friends are not dynamic and the reviews I see for the freebsd module reviews, > this is still bundled. > Right, this is an artifact of how flua's evolved that we need to move away from. We didn't have module support at the beginning- that came later, but we didn't really move things out into modules. We still can't move some things because of the bootstrap flua problem I mentioned elsewhere (doing so would block work to do `make sysent` type work as part of the build as it would break cross-builds), but at least libucl/fbsd would be fine. > my proposal for unbundling, I need kldload for a project of mine, so I did: > https://reviews.freebsd.org/D46558 > > Best regards, > Bapt From nobody Fri Sep 6 14:47:21 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 4X0fGH3CtZz5VDyg for ; Fri, 06 Sep 2024 14:47:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0fGG5k0Mz4ZlY for ; Fri, 6 Sep 2024 14:47:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2d8a7c50607so1492148a91.1 for ; Fri, 06 Sep 2024 07:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725634053; x=1726238853; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oALdjrDfuJrPVXkUPx7b7/Koki5IdQH90D7hWIPvd0g=; b=3Hw+wtBhLhVXe+ng+Gs31ZN+X2BOC03NlL5PdS7si4TLp9zcBux9ydHHOAcKZgm75I NdhuSbVbbMR5MUnuRVc4FpuL1gPn+8owMG8bJpNdaXsK85TCHyh2lSBfZwQFrOYqNo8S fYiRdQs+wNCMpT1OWw/Z9fMSAx779RFbSldnlwGZamZPq8mQ8PHy1mop4dLMy48WEqB2 FOkTjWBhjjrL9vTuG1MlTniFMJuIiQmlQwy2DZE4DaAR33lWSzezEu8H8WqwttH6iT5a CFj7Ay8dk0FhUJysyMC07138Aoz2jE94JnK6fobOUtjxf2Ecx82muSFMjBwGFv+cd6vv Hx4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725634053; x=1726238853; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oALdjrDfuJrPVXkUPx7b7/Koki5IdQH90D7hWIPvd0g=; b=lSFP3ciSEHhRtMLMEfk2ewFpNghrJB0+Y6XxEBWuS7VliT5qn/N113X3orIWkE9VX4 8OrwHoFZMkhE/mzJzoAU2qOwOsvxZMCDsQm+i3MLA7VMaAFs+knEKyF6V+/WnC2eYYqa a3pfPsGCdKHkeDmmRz0UxnhKraVsBLS+H1xqaPUXNldQMvnAIR9MJeL46CUcsOJnogwK 2kweGdGwG4rDhBKD4k7LVHddr0ZYduKmLr4l7qc9D4EDqXf5xRMSV4WOU3cQc8BdmZ7L kyBp/ZsrKdmCc5KjVOdNbFmi6gjA3b4ReZu/2la6qmuDPCdpGJV8Zv+3qwcSTOaNSDZc 6QEw== X-Gm-Message-State: AOJu0Yx8s1ujNRtsgtmbT/8mVqR/Fr88cOKscGSHiwjKyMjHYUl+0MyY BuwiH3PJ8qBIZuzTXCQECwWujesf+/b+C3VFmT6z3RarwSVrSF3qNad1fwU+fy2ZmhpjMbOUMYX ofAkmw8BBzThMWHrmCB7btvg9Sxg+YOl/70UMIQ== X-Google-Smtp-Source: AGHT+IHMYhq/po36MJ9SQjlbmSaxMmg6tbaEXS/tvPnhe3rTdoEZoT5Jx1HJ/06KxC9fR1xRmwuHxCB+zSj5HrqGajQ= X-Received: by 2002:a17:90a:bc9:b0:2d3:ba42:775c with SMTP id 98e67ed59e1d1-2dad4de1446mr3547827a91.1.1725634053322; Fri, 06 Sep 2024 07:47:33 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Fri, 6 Sep 2024 08:47:21 -0600 Message-ID: Subject: Re: adding new flua libraries To: Mark Johnston Cc: freebsd-hackers@freebsd.org, kevans@freebsd.org, imp@freebsd.org, bapt@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c2d9ea0621747c4b" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0fGG5k0Mz4ZlY --000000000000c2d9ea0621747c4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024 at 4:52=E2=80=AFPM Mark Johnston wr= ote: > FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It's > intended for use by the base system, and so far has a few consumers, but > not many so far. (As an aside, flua's intended scope is not totally > clear to me. Is it only for use by the base system? What compatibility > guarantees does it provide, if any?) > To date, it's only provided for FreeBSD provided things. That means there's close coordination between what we provide and it. In general, it should remain compatible, but I think we've taken some liberties when it wasn't widely used to, for example, go from 5.3 to 5.4 w/o providing a fully compatible 5.3 env. > A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > available, but they don't provide enough to make flua useful as a > general purpose programming tool. It lacks interfaces for interacting > with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > standard programming facilities (e.g., classes, higher-order functions, > etc.). Here I'm mostly interested in discussing the former. > Yea, LUA is a language you can build OO concepts on, but doesn't directly provide more than the building blocks. Most librairies I've seen either pick a set of wrappers, or expand the wrappers in-line. We should pick one: I'm partial to the provide a common set of wrappers model when the time comes. > I think flua could be a very useful alternative to shell scripts and C > code where performance is not critical. It's very good at wrapping C > interfaces and thus could be used to make FreeBSD features (jails, > bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > don't want to interact with C. > Yes. Last summer's GSoC code to test all the boot loader operations went great in lua until the very end when the desire to test all 50 combinations in parallel rather than serially (to reduce the run time from sneaking up on an hour to about a minute) couldn't do it in Lua, so things were rewritten in Python... > It's a lot of work to build up a set of flua modules that provide enough > functionality to be generally useful. My feeling is that the easiest > way to get there is to wrap C interfaces directly (to the extent that > that's possible, but it's usually easy) and expose them in flua as a > stable interface. Libraries written in pure Lua (or other languages > that interoperate well with Lua) could be built on top of that. > Yes. I tend to agree, though I think we may want to find a way to provide some things written in Lua and some in C for these wrapping. > I'm inclined to start by wrapping libc and libsys interfaces in a manner > similar to luaposix. There, the namespace is partitioned by C headers, > so posix.unistd contains identifiers from unistd.h, posix.sys.stat > contains identifiers from sys/stat.h, and so on. In fact, flua already > has a small subset of luaposix's functionality. Wrapping C interfaces > isn't much fun, but it's easy, and it saves us having to come up with > names and interfaces (naming things is hard), and helps ensure that the > glue code is relatively small and doesn't impose a large testing burden. > Moreover, C interfaces don't change much and are subject to > well-understood compatibility constraints, which should mean that Lua > interfaces built on top of them are subject to the same constraints. > Generally I agree, though with the caveat that I think posix module tends to have too-deep a namespace, and I'm hesitant about using that for FreeBSD, given how much clutter it would add to the lua code. > Assuming there's general agreement on that approach, the question I'd > really like to answer is, what should the namespace look like? It would > be useful to provide a posix module compatible with luaposix, but that > obviously won't contain FreeBSD-specific functionality. > > I propose having a top-level "freebsd" namespace for all modules > implemented in the base system, excluding posix and contrib libraries > which already define a Lua interface (libucl is the one example I see so > far; we could import sqlite bindings as well). Then, if we follow > luaposix's convention, we could have freebsd.sys.capsicum.* for > Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent > wrappers, and so on. The posix module could simply provide a subset of > freebsd.*. > I think that may be too hierarchical and provide little benefit. What would we have in freebsd.* that would conflict with freebsd.sys.*? I barely see the benefit for the posix module, but I think it was a mistake to do it there... but we're stuck with the design. And depending on how compatible we want to be with the posix module, this may tie our hands a bit in providing more info, or info in a better format if we try to make it strictly speaking, a subset with the implicatio= n that the behavior is identical. > Maybe it's better to separate C wrappers from native Lua modules though, > so it could be better to have freebsd.c.sys.capsicum.*, etc., and > provide higher-level interfaces for FreeBSD features under freebsd.pf, > freebsd.zfs, freebsd.jail, etc.. I'm not really sure. > I think that's going even further into the weeds. There's no reason that freebsd.zfs couldn't provide the zfs system calls. freebsd.jail the jail ones, etc, in addition to the higher levels. We're not likely going to nest multiple modules that do jail things on top of a base jail system call-only module. I'm having trouble seeing the benefit for all the extra clutter this would bring to the lua code we write. > In the interest of prompting discussion a bit, I posted some patches to > add some example wrappers to flua: > https://reviews.freebsd.org/D46553 > https://reviews.freebsd.org/D46554 > https://reviews.freebsd.org/D46556 > > Does anyone have opinions on anything I've brought up above? I'm pretty > happy to write a lot of this glue code or find ways to automate it, as > I've already done a fair bit of it, but it's hard to make progress > without having some rigourous conventions for the flua namespace (again, > naming things is hard). > We should agree on the namespace stuff, then put the conversation in our rearview mirror. :). But generally, I love the idea and any comments about how to design "the crinkly bits on the fjords" shouldn't be taken to my not liking the fjords. Warner with apologies to douglas adams --000000000000c2d9ea0621747c4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 5, 2024 at 4:52=E2=80=AFP= M Mark Johnston <markj@freebsd.org<= /a>> wrote:
F= reeBSD ships a Lua 5.4 implementation, flua, in the base system.=C2=A0 It&#= 39;s
intended for use by the base system, and so far has a few consumers, but not many so far.=C2=A0 (As an aside, flua's intended scope is not total= ly
clear to me.=C2=A0 Is it only for use by the base system?=C2=A0 What compat= ibility
guarantees does it provide, if any?)

=C2=A0
A few flua modules wrapping FreeBSD libraries (e.g., libjail) are
available, but they don't provide enough to make flua useful as a
general purpose programming tool.=C2=A0 It lacks interfaces for interacting=
with the system (e.g., libc/libsys/libutil/etc wrappers) as well as
standard programming facilities (e.g., classes, higher-order functions,
etc.).=C2=A0 Here I'm mostly interested in discussing the former.

Yea, LUA is a language you can build OO conc= epts on, but doesn't
directly provide more than the building = blocks. Most librairies I've seen
either pick a set of wrappe= rs, or expand the wrappers in-line. We should
pick one: I'm p= artial to the provide a common set of wrappers model
when the tim= e comes.
=C2=A0
I think flua could be a very useful alternative to shell scripts and C
code where performance is not critical.=C2=A0 It's very good at wrappin= g C
interfaces and thus could be used to make FreeBSD features (jails,
bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who
don't want to interact with C.

Yes.= Last summer's GSoC code to test all the boot loader operations
went great in lua until the very end when the desire to test all 50
combinations in parallel rather than serially (to reduce the run time=
from sneaking up on an hour to about a minute) couldn't do i= t in Lua,
so things were rewritten in Python...
=C2=A0<= /div>
It's a lot of work to build up a set of flua modules that provide enoug= h
functionality to be generally useful.=C2=A0 My feeling is that the easiest<= br> way to get there is to wrap C interfaces directly (to the extent that
that's possible, but it's usually easy) and expose them in flua as = a
stable interface.=C2=A0 Libraries written in pure Lua (or other languages that interoperate well with Lua) could be built on top of that.

Yes. I tend to agree, though I think we may want t= o find a way to
provide some things written in Lua and some in C = for these
wrapping.
=C2=A0
I'm inclined to start by wrapping libc and libsys interfaces in a manne= r
similar to luaposix.=C2=A0 There, the namespace is partitioned by C headers= ,
so posix.unistd contains identifiers from unistd.h, posix.sys.stat
contains identifiers from sys/stat.h, and so on.=C2=A0 In fact, flua alread= y
has a small subset of luaposix's functionality.=C2=A0 Wrapping C interf= aces
isn't much fun, but it's easy, and it saves us having to come up wi= th
names and interfaces (naming things is hard), and helps ensure that the
glue code is relatively small and doesn't impose a large testing burden= .
Moreover, C interfaces don't change much and are subject to
well-understood compatibility constraints, which should mean that Lua
interfaces built on top of them are subject to the same constraints.

Generally I agree, though with the caveat tha= t I think posix module
tends to have too-deep a namespace, and I&= #39;m hesitant about using
that for FreeBSD, given how much clutt= er it would add to the lua code.
=C2=A0
Assuming there's general agreement on that approach, the question I'= ;d
really like to answer is, what should the namespace look like?=C2=A0 It wou= ld
be useful to provide a posix module compatible with luaposix, but that
obviously won't contain FreeBSD-specific functionality.

I propose having a top-level "freebsd" namespace for all modules<= br> implemented in the base system, excluding posix and contrib libraries
which already define a Lua interface (libucl is the one example I see so far; we could import sqlite bindings as well).=C2=A0 Then, if we follow
luaposix's convention, we could have freebsd.sys.capsicum.* for
Capsicum-related syscalls and constants, freebsd.sys.event.* for kevent
wrappers, and so on.=C2=A0 The posix module could simply provide a subset o= f
freebsd.*.

I think that may be too hier= archical and provide little benefit. What would
we have in freebs= d.* that would conflict with freebsd.sys.*? I barely see the
bene= fit for the posix module, but I think it was a mistake to do it there... bu= t
we're stuck with the design.

And d= epending on how compatible we want to be with the posix module,
t= his may tie our hands a bit in providing more info, or info in a better
format if we try to make it strictly speaking, a subset with the imp= lication
that the behavior is identical.
=C2=A0
Maybe it's better to separate C wrappers from native Lua modules though= ,
so it could be better to have freebsd.c.sys.capsicum.*, etc., and
provide higher-level interfaces for FreeBSD features under freebsd.pf,
freebsd.zfs, freebsd.jail, etc..=C2=A0 I'm not really sure.

I think that's going even further into the wee= ds. There's no reason
that freebsd.zfs couldn't provide t= he zfs system calls. freebsd.jail the jail
ones, etc, in addition= to the higher levels. We're not likely going to nest
multipl= e modules that do jail things on top of a base jail system call-only
<= div>module. I'm having trouble seeing the benefit for all the extra clu= tter
this would bring to the lua code we write.
=C2=A0<= /div>
In the interest of prompting discussion a bit, I posted some patches to
add some example wrappers to flua:
https://reviews.freebsd.org/D46553
https://reviews.freebsd.org/D46554
https://reviews.freebsd.org/D46556

Does anyone have opinions on anything I've brought up above?=C2=A0 I= 9;m pretty
happy to write a lot of this glue code or find ways to automate it, as
I've already done a fair bit of it, but it's hard to make progress<= br> without having some rigourous conventions for the flua namespace (again, naming things is hard).

We should agree= on the namespace stuff, then put the conversation in our
rearvie= w mirror. :).

But generally, I love the idea and a= ny comments about how to design "the crinkly=C2=A0bits on the fjords&q= uot;
shouldn't be taken to my not liking the fjords.

Warner

with apologies to douglas = adams
--000000000000c2d9ea0621747c4b-- From nobody Fri Sep 6 14:48:59 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 4X0fJ84wpsz5VDwq for ; Fri, 06 Sep 2024 14:49:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0fJ83S7Sz4bw7 for ; Fri, 6 Sep 2024 14:49:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2da55ea8163so1594877a91.1 for ; Fri, 06 Sep 2024 07:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725634151; x=1726238951; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UnQoLlCQVcdA3krTyWMnqt89ADwgqV5U25SGKWmv7Bs=; b=WWkRv/+hV6Bup9UzZjrMVE+hl9vCkOr9A3d32pk+PCba0Ka73arw2yaDViWSIeIS7A QLLuRY8ZdDl299N9USZgPulVwV4ki2QvLrV3x8DaWSONhiFeAgeSsi1YfXIiLWv7xrPj DXU8wFuxAE3OsSEJ++aBVtAkPOJjmJME9G6A9SeITDp96mJiV1uR0jT3w1A+dN3rIIA4 coNNZsXkHqRc6hWZamjplOWI4P+1PJo2y2C8XktPMhSXR+GU1XKDax8RNcHRoANZ92nu wh/Zt3hUa9pJub/LeR7RvQ4YMkT/ksg9G2UAuMgQCMxjNH8zEbCpEDW8E42tlo/lKaDN 3BwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725634151; x=1726238951; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UnQoLlCQVcdA3krTyWMnqt89ADwgqV5U25SGKWmv7Bs=; b=qUwhRaMPKMQ1yebFVgglDJfOP3J6JpB8affSqINAlxdYSp4FlDNts8X8/h+XbCx/hJ mauKJo0vMKDCzGW39IWlBDFhn+csty0yfWIjDlvBkyv1kvHC9OGh7fAf00OSDVEYlDtA jdTun9pUzUp5+6rW2+q4wWg1iunImNa053IflHjK6o8K0yICmCGyuMoCXseMoMNnAmWH 0+Pojn00owZyhU+mjmL5tpHJA1NreCxq5QUJYxqm5VAphc80W7svHU/OZLKrsY0QAtGv OBXs+Ah1LGuhxW3ggEy4ktDfDBmSTRA3J3u36UAng5jbxu+258ukSIweOB0vs3hVWgZd bMsA== X-Forwarded-Encrypted: i=1; AJvYcCXbV3eI9PtcwlApcu32qpB799N2BC1SINkLUss9yfS1Em1GDSU0qUK3/xXq0XyIh5xQPYRljxCeF3dboNqnfAo=@freebsd.org X-Gm-Message-State: AOJu0YyFr5e1cEgPyXt9dMapkW69rBfMPpr5wLy0/0hXZRGUcBxpEUMw nTOsxeraY9JKtZfn2YJYpBTwh+iU/Fk8kv+adoAFxnZMDBo4QeXvKNscQ7lYgs8QUxqFqOKTZXO v8s7lbcuMAsQ649xLUKWhbh9ydb3zwaGV0ucp7NY3L/fSAmxx X-Google-Smtp-Source: AGHT+IH+yQ2SL51hMow0n76Df03dmT3UADOiqscixwj3dcj6JSZx9kRWDY+s104DieB8hDpwmgvGyneLmVwqG0ccZC8= X-Received: by 2002:a17:90a:304a:b0:2d8:82a2:b093 with SMTP id 98e67ed59e1d1-2dad50d297cmr3386458a91.13.1725634150916; Fri, 06 Sep 2024 07:49:10 -0700 (PDT) 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 References: <2f3039bc-883c-4b11-ab20-d1873c6cc555@FreeBSD.org> In-Reply-To: <2f3039bc-883c-4b11-ab20-d1873c6cc555@FreeBSD.org> From: Warner Losh Date: Fri, 6 Sep 2024 08:48:59 -0600 Message-ID: Subject: Re: adding new flua libraries To: Kyle Evans Cc: Baptiste Daroussin , Mark Johnston , freebsd-hackers@freebsd.org, imp@freebsd.org Content-Type: multipart/alternative; boundary="00000000000094008c0621748294" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0fJ83S7Sz4bw7 --00000000000094008c0621748294 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 6, 2024 at 8:45=E2=80=AFAM Kyle Evans wrot= e: > On 9/6/24 04:29, Baptiste Daroussin wrote: > > On Thu 05 Sep 18:51, Mark Johnston wrote: > >> FreeBSD ships a Lua 5.4 implementation, flua, in the base system. It'= s > >> intended for use by the base system, and so far has a few consumers, b= ut > >> not many so far. (As an aside, flua's intended scope is not totally > >> clear to me. Is it only for use by the base system? What compatibili= ty > >> guarantees does it provide, if any?) > >> > >> A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > >> available, but they don't provide enough to make flua useful as a > >> general purpose programming tool. It lacks interfaces for interacting > >> with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > >> standard programming facilities (e.g., classes, higher-order functions= , > >> etc.). Here I'm mostly interested in discussing the former. > >> > >> I think flua could be a very useful alternative to shell scripts and C > >> code where performance is not critical. It's very good at wrapping C > >> interfaces and thus could be used to make FreeBSD features (jails, > >> bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > >> don't want to interact with C. > >> > >> It's a lot of work to build up a set of flua modules that provide enou= gh > >> functionality to be generally useful. My feeling is that the easiest > >> way to get there is to wrap C interfaces directly (to the extent that > >> that's possible, but it's usually easy) and expose them in flua as a > >> stable interface. Libraries written in pure Lua (or other languages > >> that interoperate well with Lua) could be built on top of that. > >> > >> I'm inclined to start by wrapping libc and libsys interfaces in a mann= er > >> similar to luaposix. There, the namespace is partitioned by C headers= , > >> so posix.unistd contains identifiers from unistd.h, posix.sys.stat > >> contains identifiers from sys/stat.h, and so on. In fact, flua alread= y > >> has a small subset of luaposix's functionality. Wrapping C interfaces > >> isn't much fun, but it's easy, and it saves us having to come up with > >> names and interfaces (naming things is hard), and helps ensure that th= e > >> glue code is relatively small and doesn't impose a large testing burde= n. > >> Moreover, C interfaces don't change much and are subject to > >> well-understood compatibility constraints, which should mean that Lua > >> interfaces built on top of them are subject to the same constraints. > >> > >> Assuming there's general agreement on that approach, the question I'd > >> really like to answer is, what should the namespace look like? It wou= ld > >> be useful to provide a posix module compatible with luaposix, but that > >> obviously won't contain FreeBSD-specific functionality. > >> > >> I propose having a top-level "freebsd" namespace for all modules > >> implemented in the base system, excluding posix and contrib libraries > >> which already define a Lua interface (libucl is the one example I see = so > >> far; we could import sqlite bindings as well). Then, if we follow > >> luaposix's convention, we could have freebsd.sys.capsicum.* for > >> Capsicum-related syscalls and constants, freebsd.sys.event.* for keven= t > >> wrappers, and so on. The posix module could simply provide a subset o= f > >> freebsd.*. > >> > >> Maybe it's better to separate C wrappers from native Lua modules thoug= h, > >> so it could be better to have freebsd.c.sys.capsicum.*, etc., and > >> provide higher-level interfaces for FreeBSD features under freebsd.pf, > >> freebsd.zfs, freebsd.jail, etc.. I'm not really sure. > >> > >> In the interest of prompting discussion a bit, I posted some patches t= o > >> add some example wrappers to flua: > >> https://reviews.freebsd.org/D46553 > >> https://reviews.freebsd.org/D46554 > >> https://reviews.freebsd.org/D46556 > >> > >> Does anyone have opinions on anything I've brought up above? I'm pret= ty > >> happy to write a lot of this glue code or find ways to automate it, as > >> I've already done a fair bit of it, but it's hard to make progress > >> without having some rigourous conventions for the flua namespace (agai= n, > >> naming things is hard). > > > > I like all of what I read and I am fully aligned. > > > > What I don't see here, is I think we should have dynamic modules libucl= , > fbsd & > > friends are not dynamic and the reviews I see for the freebsd module > reviews, > > this is still bundled. > > > > Right, this is an artifact of how flua's evolved that we need to move > away from. We didn't have module support at the beginning- that came > later, but we didn't really move things out into modules. We still > can't move some things because of the bootstrap flua problem I mentioned > elsewhere (doing so would block work to do `make sysent` type work as > part of the build as it would break cross-builds), but at least > libucl/fbsd would be fine. > Yea, if the sysent.lua code doesn't use modules, would we still have the same bootstrapping issues? Today, I don't think here's anything but vanilla lua code in there. Warner > > my proposal for unbundling, I need kldload for a project of mine, so I > did: > > https://reviews.freebsd.org/D46558 > > > > Best regards, > > Bapt > > --00000000000094008c0621748294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 6, 2024 at 8:45=E2=80=AFA= M Kyle Evans <kevans@freebsd.org> wrote:
On= 9/6/24 04:29, Baptiste Daroussin wrote:
> On Thu 05 Sep 18:51, Mark Johnston wrote:
>> FreeBSD ships a Lua 5.4 implementation, flua, in the base system.= =C2=A0 It's
>> intended for use by the base system, and so far has a few consumer= s, but
>> not many so far.=C2=A0 (As an aside, flua's intended scope is = not totally
>> clear to me.=C2=A0 Is it only for use by the base system?=C2=A0 Wh= at compatibility
>> guarantees does it provide, if any?)
>>
>> A few flua modules wrapping FreeBSD libraries (e.g., libjail) are<= br> >> available, but they don't provide enough to make flua useful a= s a
>> general purpose programming tool.=C2=A0 It lacks interfaces for in= teracting
>> with the system (e.g., libc/libsys/libutil/etc wrappers) as well a= s
>> standard programming facilities (e.g., classes, higher-order funct= ions,
>> etc.).=C2=A0 Here I'm mostly interested in discussing the form= er.
>>
>> I think flua could be a very useful alternative to shell scripts a= nd C
>> code where performance is not critical.=C2=A0 It's very good a= t wrapping C
>> interfaces and thus could be used to make FreeBSD features (jails,=
>> bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers wh= o
>> don't want to interact with C.
>>
>> It's a lot of work to build up a set of flua modules that prov= ide enough
>> functionality to be generally useful.=C2=A0 My feeling is that the= easiest
>> way to get there is to wrap C interfaces directly (to the extent t= hat
>> that's possible, but it's usually easy) and expose them in= flua as a
>> stable interface.=C2=A0 Libraries written in pure Lua (or other la= nguages
>> that interoperate well with Lua) could be built on top of that. >>
>> I'm inclined to start by wrapping libc and libsys interfaces i= n a manner
>> similar to luaposix.=C2=A0 There, the namespace is partitioned by = C headers,
>> so posix.unistd contains identifiers from unistd.h, posix.sys.stat=
>> contains identifiers from sys/stat.h, and so on.=C2=A0 In fact, fl= ua already
>> has a small subset of luaposix's functionality.=C2=A0 Wrapping= C interfaces
>> isn't much fun, but it's easy, and it saves us having to c= ome up with
>> names and interfaces (naming things is hard), and helps ensure tha= t the
>> glue code is relatively small and doesn't impose a large testi= ng burden.
>> Moreover, C interfaces don't change much and are subject to >> well-understood compatibility constraints, which should mean that = Lua
>> interfaces built on top of them are subject to the same constraint= s.
>>
>> Assuming there's general agreement on that approach, the quest= ion I'd
>> really like to answer is, what should the namespace look like?=C2= =A0 It would
>> be useful to provide a posix module compatible with luaposix, but = that
>> obviously won't contain FreeBSD-specific functionality.
>>
>> I propose having a top-level "freebsd" namespace for all= modules
>> implemented in the base system, excluding posix and contrib librar= ies
>> which already define a Lua interface (libucl is the one example I = see so
>> far; we could import sqlite bindings as well).=C2=A0 Then, if we f= ollow
>> luaposix's convention, we could have freebsd.sys.capsicum.* fo= r
>> Capsicum-related syscalls and constants, freebsd.sys.event.* for k= event
>> wrappers, and so on.=C2=A0 The posix module could simply provide a= subset of
>> freebsd.*.
>>
>> Maybe it's better to separate C wrappers from native Lua modul= es though,
>> so it could be better to have freebsd.c.sys.capsicum.*, etc., and<= br> >> provide higher-level interfaces for FreeBSD features under freebsd.pf,=
>> freebsd.zfs, freebsd.jail, etc..=C2=A0 I'm not really sure. >>
>> In the interest of prompting discussion a bit, I posted some patch= es to
>> add some example wrappers to flua:
>> https://reviews.freebsd.org/D46553
>> https://reviews.freebsd.org/D46554
>> https://reviews.freebsd.org/D46556
>>
>> Does anyone have opinions on anything I've brought up above?= =C2=A0 I'm pretty
>> happy to write a lot of this glue code or find ways to automate it= , as
>> I've already done a fair bit of it, but it's hard to make = progress
>> without having some rigourous conventions for the flua namespace (= again,
>> naming things is hard).
>
> I like all of what I read and I am fully aligned.
>
> What I don't see here, is I think we should have dynamic modules l= ibucl, fbsd &
> friends are not dynamic and the reviews I see for the freebsd module r= eviews,
> this is still bundled.
>

Right, this is an artifact of how flua's evolved that we need to move <= br> away from.=C2=A0 We didn't have module support at the beginning- that c= ame
later, but we didn't really move things out into modules.=C2=A0 We stil= l
can't move some things because of the bootstrap flua problem I mentione= d
elsewhere (doing so would block work to do `make sysent` type work as
part of the build as it would break cross-builds), but at least
libucl/fbsd would be fine.

Yea, if the = sysent.lua code doesn't use modules, would we still have the same
=
bootstrapping issues? Today, I don't think here's anything but= vanilla lua code
in there.

Warner
=
=C2=A0
> my proposal for unbundling, I need kldload for a project of mine, so I= did:
> https://reviews.freebsd.org/D46558
>
> Best regards,
> Bapt

--00000000000094008c0621748294-- From nobody Fri Sep 6 14:51:45 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 4X0fM656BRz5VF0l for ; Fri, 06 Sep 2024 14:51:46 +0000 (UTC) (envelope-from kevans@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 4X0fM64Pz6z4ckJ; Fri, 6 Sep 2024 14:51:46 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725634306; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ff9BiinzVZJnuGwZLJJqw6VsoNsirSxOWy+IEHIsOSk=; b=MjA2PeWdFBPHeFTay/bhVo9OCsN7No+d+hHl1cGgv2RzMo/qGCSDe3W1+6yP7egQmgpqel Dkk9nqYZJpksNqJlpZmHGD8Ih4u3KC9TDNAkbQkQdYAFEBpDn4yj5ZvAj3yHYuOT/iT06B ttrbWJDfofaOM4VgjsNEKINDDl/4+q9xaYrqzH7KDg3FvKo/pyc2j1PJK3wtYC5NVhM11Z W118EyqRmo9WGQrSqxmJvpvEwCPlM96YAIQ+xnSDFESb7/H6sLM9+7daFu7vZrYntFcJc+ uCBVIelZirKF0dTt/M2/8MuzL59juzSm6fcU8w+aI1v7cTk2Z0iDFr5LUJvbdg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725634306; a=rsa-sha256; cv=none; b=rO/E/zMupzZajAxoFJTz7UV3Lz/gqNFQDX5Lm1EDrLXunrQHxX1J2Qn4taEMhbnxj3WGaq ha3mCiYqFhU17E6QujbIizZ7c0LXRk5QM2DZMD/JAxfxikRbenVzv6WLNt4hjgndNB+Qdn s6aZxyXumV/KaHXcVgtt/YDdsV6ScBfk//u0TXZHeCso62WbxFUTZnMfW+avzb9wSm5r2N kYrr8Ov32n1jtEvkbhpGvmJkKgxJOctMydTBIXUyjqs0k01QvemYk0Fp0UitpbgbAwKRdV QjKU5R5sFNW/4rMFPkCkNbFNTAXiealgsOilxJUv0TU/A1wuXclvYcE6Q2ibQQ== 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=1725634306; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ff9BiinzVZJnuGwZLJJqw6VsoNsirSxOWy+IEHIsOSk=; b=wm2ZLcmiiW6wB6c3QgLvZ96T2yesiKIWU4AcxQKMbBFLAAlMxeRyn+nKtM+3NCv7gPQNYn bRt+O7p95UtLUHY//rctT7LXRKkl0Kdu8QxZp3vd1h/z+laM4rgZjb98T++0C/EprREE9Y mYglWUwReozZ5mSV4iP2WCp4fVYVVy5MVOy9qKIOgRD2WQThnGXGGb7eqpfdl549LbEzh6 1w4HRYv9BuVrIqq50I49ojgNoqk6twp6DI/0L2LA+bbnWaB7WSPCTJ5CHn4s1g/fZ9sn4H YaagRWnotAoWnD0y75uJmBjSZqMbJPEDi8wAGfoW83bKQ7eq2hemoh8Rruu9lA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0fM60hgczQkP; Fri, 6 Sep 2024 14:51:46 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <4b06cc12-104a-4ee5-bc92-d9ccec18fe3f@FreeBSD.org> Date: Fri, 6 Sep 2024 09:51:45 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: adding new flua libraries To: Warner Losh Cc: Baptiste Daroussin , Mark Johnston , freebsd-hackers@freebsd.org, imp@freebsd.org References: <2f3039bc-883c-4b11-ab20-d1873c6cc555@FreeBSD.org> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/6/24 09:48, Warner Losh wrote: > > > On Fri, Sep 6, 2024 at 8:45 AM Kyle Evans > wrote: > > On 9/6/24 04:29, Baptiste Daroussin wrote: > > On Thu 05 Sep 18:51, Mark Johnston wrote: > >> FreeBSD ships a Lua 5.4 implementation, flua, in the base > system.  It's > >> intended for use by the base system, and so far has a few > consumers, but > >> not many so far.  (As an aside, flua's intended scope is not totally > >> clear to me.  Is it only for use by the base system?  What > compatibility > >> guarantees does it provide, if any?) > >> > >> A few flua modules wrapping FreeBSD libraries (e.g., libjail) are > >> available, but they don't provide enough to make flua useful as a > >> general purpose programming tool.  It lacks interfaces for > interacting > >> with the system (e.g., libc/libsys/libutil/etc wrappers) as well as > >> standard programming facilities (e.g., classes, higher-order > functions, > >> etc.).  Here I'm mostly interested in discussing the former. > >> > >> I think flua could be a very useful alternative to shell scripts > and C > >> code where performance is not critical.  It's very good at > wrapping C > >> interfaces and thus could be used to make FreeBSD features (jails, > >> bhyve, ctl, pf, zfs, dtrace, ...) more accessible to developers who > >> don't want to interact with C. > >> > >> It's a lot of work to build up a set of flua modules that > provide enough > >> functionality to be generally useful.  My feeling is that the > easiest > >> way to get there is to wrap C interfaces directly (to the extent > that > >> that's possible, but it's usually easy) and expose them in flua as a > >> stable interface.  Libraries written in pure Lua (or other languages > >> that interoperate well with Lua) could be built on top of that. > >> > >> I'm inclined to start by wrapping libc and libsys interfaces in > a manner > >> similar to luaposix.  There, the namespace is partitioned by C > headers, > >> so posix.unistd contains identifiers from unistd.h, posix.sys.stat > >> contains identifiers from sys/stat.h, and so on.  In fact, flua > already > >> has a small subset of luaposix's functionality.  Wrapping C > interfaces > >> isn't much fun, but it's easy, and it saves us having to come up > with > >> names and interfaces (naming things is hard), and helps ensure > that the > >> glue code is relatively small and doesn't impose a large testing > burden. > >> Moreover, C interfaces don't change much and are subject to > >> well-understood compatibility constraints, which should mean > that Lua > >> interfaces built on top of them are subject to the same constraints. > >> > >> Assuming there's general agreement on that approach, the > question I'd > >> really like to answer is, what should the namespace look like? > It would > >> be useful to provide a posix module compatible with luaposix, > but that > >> obviously won't contain FreeBSD-specific functionality. > >> > >> I propose having a top-level "freebsd" namespace for all modules > >> implemented in the base system, excluding posix and contrib > libraries > >> which already define a Lua interface (libucl is the one example > I see so > >> far; we could import sqlite bindings as well).  Then, if we follow > >> luaposix's convention, we could have freebsd.sys.capsicum.* for > >> Capsicum-related syscalls and constants, freebsd.sys.event.* for > kevent > >> wrappers, and so on.  The posix module could simply provide a > subset of > >> freebsd.*. > >> > >> Maybe it's better to separate C wrappers from native Lua modules > though, > >> so it could be better to have freebsd.c.sys.capsicum.*, etc., and > >> provide higher-level interfaces for FreeBSD features under > freebsd.pf , > >> freebsd.zfs, freebsd.jail, etc..  I'm not really sure. > >> > >> In the interest of prompting discussion a bit, I posted some > patches to > >> add some example wrappers to flua: > >> https://reviews.freebsd.org/D46553 > > >> https://reviews.freebsd.org/D46554 > > >> https://reviews.freebsd.org/D46556 > > >> > >> Does anyone have opinions on anything I've brought up above? > I'm pretty > >> happy to write a lot of this glue code or find ways to automate > it, as > >> I've already done a fair bit of it, but it's hard to make progress > >> without having some rigourous conventions for the flua namespace > (again, > >> naming things is hard). > > > > I like all of what I read and I am fully aligned. > > > > What I don't see here, is I think we should have dynamic modules > libucl, fbsd & > > friends are not dynamic and the reviews I see for the freebsd > module reviews, > > this is still bundled. > > > > Right, this is an artifact of how flua's evolved that we need to move > away from.  We didn't have module support at the beginning- that came > later, but we didn't really move things out into modules.  We still > can't move some things because of the bootstrap flua problem I > mentioned > elsewhere (doing so would block work to do `make sysent` type work as > part of the build as it would break cross-builds), but at least > libucl/fbsd would be fine. > > > Yea, if the sysent.lua code doesn't use modules, would we still have the > same > bootstrapping issues? Today, I don't think here's anything but vanilla > lua code > in there. > Right- if it didn't we'd have no problem, but the in-tree version uses lposix to construct a tmpdir to throw the intermediate files in while we're building them. I suppose the new model would more likely generate them in-place in .OBJDIR instead and could avoid that. From nobody Fri Sep 6 15:54:21 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 4X0glP1Kr0z5VNQj for ; Fri, 06 Sep 2024 15:54:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0glN2vgPz4pjY for ; Fri, 6 Sep 2024 15:54:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=troutmask.apl.washington.edu header.s=troutmask header.b=jVNNvYjt; dmarc=fail reason="No valid SPF" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.18.1/8.18.1) with ESMTP id 486FsMtZ014978 for ; Fri, 6 Sep 2024 08:54:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 486FsMtZ014978 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1725638062; bh=0/CIx2X1UTJ7nUASWZp95V+yBZN3Il2ENV5fMdrmW+U=; h=Date:From:To:Subject:Reply-To:From; b=jVNNvYjtbwQLxoSqPalBE0gSiSI71Zy5kxUvOmEI9KO7Zs4OA6wKCwSS3Kt6LdXei BH85k2IL8wMYv3rKlHfGNmOiscq2yr/bxvZK45KDVoodOYgr4v49GgOAAPsqu6y3l6 bEvWIAHLqw4uWXK1sS+ny857dfp5QGh89eMnwX40L+8nHby2Z534cj0nsWbBxkUgMx oeYN5xT9D8wkPBXoAHxSkh4dYf6aT2z/WPc0xt26p3PIL3ZwVNeOuJuNPqVTjHw7iz UjxdVFBZ9LpPD8kJxFYGY2lZfxqLlK0a49fjZMHeBmkcyWHWMR8CtH0QLpFGSs/+PS rr4nYhC+XTLzQ== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.18.1/8.18.1/Submit) id 486FsL7V014977 for freebsd-hackers@freebsd.org; Fri, 6 Sep 2024 08:54:21 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Sep 2024 08:54:21 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: New lock-order reversal Message-ID: Reply-To: sgk@troutmask.apl.washington.edu 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: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF,none]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[128.95.76.21:from]; R_DKIM_PERMFAIL(0.00)[troutmask.apl.washington.edu:s=troutmask]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[troutmask.apl.washington.edu:~] X-Rspamd-Queue-Id: 4X0glN2vgPz4pjY FYI (and return hackers to a non-language) Update my old system to circa Aug 10, 2024 top-of-tree and rebuilts all installed ports. I'm now see a new lock-order reversal while using openvpn. lock order reversal: 1st 0xfffff801e5482aa0 udpinp (udpinp, rw) @ /usr/src/sys/netinet/udp_usrreq.c:1129 2nd 0xfffff80003510188 if_ovpn_lock (if_ovpn_lock, rm) @ /usr/src/sys/net/if_ovpn.c:2118 lock order if_ovpn_lock -> udpinp established at: #0 0xffffffff80ba66fa at witness_checkorder+0x32a #1 0xffffffff80b2d692 at _rw_wlock_cookie+0x62 #2 0xffffffff80d45e4e at udp_set_kernel_tunneling+0x4e #3 0xffffffff82a783a1 at ovpn_ioctl_set+0xe81 #4 0xffffffff82a76df8 at ovpn_ioctl+0xf8 #5 0xffffffff80c62179 at ifioctl+0x949 #6 0xffffffff80bacd26 at kern_ioctl+0x286 #7 0xffffffff80baca3d at sys_ioctl+0x12d #8 0xffffffff8104b018 at amd64_syscall+0x158 #9 0xffffffff8101d73b at fast_syscall_common+0xf8 lock order udpinp -> if_ovpn_lock attempted at: #0 0xffffffff80ba6f75 at witness_checkorder+0xba5 #1 0xffffffff80b2c22c at _rm_rlock_debug+0x12c #2 0xffffffff82a76e91 at ovpn_output+0x41 #3 0xffffffff80d0e1ce at ip_output+0x150e #4 0xffffffff80d45ad9 at udp_send+0xa69 #5 0xffffffff80be56d1 at sosend_dgram+0x311 #6 0xffffffff80be62b9 at sousrsend+0x79 #7 0xffffffff80bec35c at kern_sendit+0x1bc #8 0xffffffff80bec66b at sendit+0x1ab #9 0xffffffff80bec4ad at sys_sendto+0x4d #10 0xffffffff8104b018 at amd64_syscall+0x158 #11 0xffffffff8101d73b at fast_syscall_common+0xf8 -- Steve From nobody Fri Sep 6 16:00:30 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 4X0gtW1FKnz5VPC5 for ; Fri, 06 Sep 2024 16:00:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0gtV0hJnz4rXN; Fri, 6 Sep 2024 16:00:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id A6A0F8928B; Fri, 06 Sep 2024 16:00:31 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 486G0UrR046040; Fri, 6 Sep 2024 16:00:30 GMT (envelope-from phk) Message-Id: <202409061600.486G0UrR046040@critter.freebsd.dk> To: Daniel Eischen cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> From: "Poul-Henning Kamp" References: <202409060836.4868agnQ042462@critter.freebsd.dk> <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> 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: text/plain; charset="us-ascii" Content-ID: <46038.1725638430.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 16:00:30 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X0gtV0hJnz4rXN -------- Daniel Eischen writes: > And back in the 80s, Ada was supposed to be the answer for safe coding l= anguage. And it seems to have done quite well. Show me any other language which has developed something like SPARK ? I think Ada's problem was that it was a "DoD language" so everything was priced 10 times what it should have been, (because why not when you can get away with it...) -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Sep 6 16:07:54 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 4X0h323Kpkz5VQ4M for ; Fri, 06 Sep 2024 16:07:58 +0000 (UTC) (envelope-from domagoj.stolfa@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0h315fSDz4ssL; Fri, 6 Sep 2024 16:07:57 +0000 (UTC) (envelope-from domagoj.stolfa@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-42bbd0a40faso19185935e9.1; Fri, 06 Sep 2024 09:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725638876; x=1726243676; darn=freebsd.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=9mWd8cOB1k73SC5I6s7P96qUMNqvucWIrVZClvQNc8o=; b=gplIS/KhERYKit5PPkSTPgHtMUNXDKgpKzCtHm7csHDyVA2Objgh9m+3DejJYDruyp +AfC5hdLn3JluuKAguC+6z8RMobiJnE4EzCzNh8LSqzDwJaJUaHgCgAJf0eaDX96MEO9 lwsAWcgrPvNwdBS8m3TyKuU9z4VD+x2uVe4J0wDp3k94Q6cHtDYFGZzCO6FirkV1Bubk MP2F7PoPAFnaZdXfs2JBhS1YLKyIvTggWnt93EgN5LJ80n0WMUedSs5qlyjzJiF3keot t3bOSPtxuv6DJ1LkFsGh6gGeAl5+IfFGVOcFktGL1w8+8ZdT/raUhUUpYvqcQaU0arpS IpMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725638876; x=1726243676; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=9mWd8cOB1k73SC5I6s7P96qUMNqvucWIrVZClvQNc8o=; b=oT6W7tTMv+vgOpx53yReGLe+wxBBQs5RDXG+kmhTJpkbgSdyFa0mzGUsP9w6jIB/ko h7/LtEzCga7DWQRSapCD/lt+FDlfmlm+WMFv6BCxBkPk1/JYvHFdHQvjNSchFDQacgSx N9oov8uJMamMe+z0NL6fo5NCxIxgKc5qBiMQnlTOoubhpc0X0WT51qLWhDVQ30YM/HhQ SdE29kL1DPJaRb9dmTwmg5RgZXpcAMnf8OYCBKfp5LoelQOxdNrB4exF8rmAg8Mp3tvs NF2ERLpjL6SAQa5+daGuMnQ+cRuyKu+N2MQENxy1gSC5L4o0dsRwfAdZg8KTxaOppFX6 CDog== X-Forwarded-Encrypted: i=1; AJvYcCUwuuZ7TQcW0TDPLMtG6R5v90fnlFOM3/lMPMR2XbU1OyXP5GlWoVSVTnwlV0YP3BWWP3x4MfFk@freebsd.org, AJvYcCW1oT8qt1oaFOL9OkZubmgP4LM4mmmx3Qz4/2AeejTnRNEvcldf9/R2YrjbDLKu902C87W7JpzkSpbWaM1h990P@freebsd.org X-Gm-Message-State: AOJu0YzfwGjmy0Uh0fte+AC1rWlmHUcUAwyvZzXH+NJ1tKsyxZfyZqn7 eR456s2fFAdpzsD2DetknHZ5DyI0Nx9n6t1BMYWRFnTgpyijKelpNUDOqYve X-Google-Smtp-Source: AGHT+IHnsUuzZSNQaj4EFYBnBqnGxS5mOgfxxdFMzhmCJOF3HS8X4Ows9XElyvMLkGw/6y+N5bq6rA== X-Received: by 2002:a05:600c:4fd6:b0:426:58ca:5a3 with SMTP id 5b1f17b1804b1-42c9f9e13f5mr22198015e9.30.1725638875420; Fri, 06 Sep 2024 09:07:55 -0700 (PDT) Received: from [10.135.7.204] ([141.98.252.203]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ca05d8a40sm25335305e9.37.2024.09.06.09.07.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Sep 2024 09:07:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------TyQtov4SyN0nuGmwg1aplyAJ" Message-ID: <1970de13-6715-4a08-8fc5-328dcadfd1ca@gmail.com> Date: Fri, 6 Sep 2024 17:07:54 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Poul-Henning Kamp , Daniel Eischen Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers References: <202409060836.4868agnQ042462@critter.freebsd.dk> <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> <202409061600.486G0UrR046040@critter.freebsd.dk> Content-Language: en-US From: Domagoj Stolfa In-Reply-To: <202409061600.486G0UrR046040@critter.freebsd.dk> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X0h315fSDz4ssL This is a multi-part message in MIME format. --------------TyQtov4SyN0nuGmwg1aplyAJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 06/09/2024 17:00, Poul-Henning Kamp wrote: > Show me any other language which has developed something like SPARK ? Unrelated to the topic at hand, but I just thought I'd throw this in the mix since it's also based on Hoare triples and some might find it interesting: https://en.wikipedia.org/wiki/Dafny. --------------TyQtov4SyN0nuGmwg1aplyAJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 06/09/2024 17:00, Poul-Henning Kamp wrote: 
Show me any other language which has developed something like SPARK ?


Unrelated to the topic at hand, but I just thought I'd throw this in the mix since it's also based on Hoare triples and some might find it interesting: https://en.wikipedia.org/wiki/Dafny.

--------------TyQtov4SyN0nuGmwg1aplyAJ-- From nobody Fri Sep 6 16:41:50 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 4X0hpD1Tvhz5VTQW for ; Fri, 06 Sep 2024 16:41:56 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from kachina.jetcafe.org (kachina.jetcafe.org [216.86.209.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "jetcafe.org", Issuer "E5" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0hpC5tNdz3yDX; Fri, 6 Sep 2024 16:41:55 +0000 (UTC) (envelope-from antranigv@freebsd.am) Authentication-Results: mx1.freebsd.org; none X-Envelope-To: freebsd-hackers@freebsd.org X-Rcpt-Mailer: X-Mail-Mailer: esmtp X-SMTP-Proto: ESMTP Received: from bigus.dream-tech.com (bigus.jetcafe.org [216.86.209.7]) by jetcafe.org (8.18.1/8.18.1) with ESMTP id 486GfoeO082234; Fri, 6 Sep 2024 09:41:50 -0700 (PDT) (envelope-from antranigv@freebsd.am) Date: Fri, 6 Sep 2024 09:41:50 -0700 From: Antranig Vartanian To: "Poul-Henning Kamp" Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: <20240906094150.799112f4@bigus.dream-tech.com> In-Reply-To: <202409060836.4868agnQ042462@critter.freebsd.dk> References: <202409060836.4868agnQ042462@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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -1 ( out of 6) ALL_TRUSTED,SHORTCIRCUIT X-Spam-Checker-Version: SpamAssassin version 4.0.1-jetcafeglobal X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12028, ipnet:216.86.192.0/19, country:US] X-Rspamd-Queue-Id: 4X0hpC5tNdz3yDX On Fri, 06 Sep 2024 08:36:42 +0000, "Poul-Henning Kamp" wrote: >But as I said in an email a couple of days ago: We should not >anoint some particular subset of programming languages or other. > >We should answer the question "What is FreeBSD?" in a way which >does not contain a very short and controversial list of "approved >programming languages". > >A pkg-based FreeBSD will allow the Rust people to write good code >for FreeBSD in Rust, and C, C++, Go, Lua, OBERON or Ada can freely >compete with them, without causing year-long slug-fests on the >mailing lists. So I think you have a good point when you talk about a pkg based FreeBSD. People rarely see what is right in front of their faces. The large number of computer languages should remind everyone of the "tower of babel" mythology. With that in mind, I claim that there will never be a "one right and true" language, ever. Thus, FreeBSD should be modular in that regard, allowing people to pick what they want. That kind of modularity is not easy or quick to implement properly, but it "should" be the way to go and at one point was the "FreeBSD way". As long as we are talking "should bes", I really don't think anyone should discuss the question "What is FreeBSD?". That will be an endless philosophical debate, which I suspect is a red herring you threw out to make an experiential point. However, now that you asked said question, I predict the discussion over -that- question will be endless. Way to go. ;) -- Dave Hayes - Computer and Internet Consultant - LA CA, USA >> *Opinions expressed above are entirely my own* << People today are in danger of drowning in information. However, because they have been taught that information is really useful, they are more willing to drown than they need be. If they could handle information, they would not have to drown at all. From nobody Fri Sep 6 16:48:53 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 4X0hyJ1hyLz5VV3Y for ; Fri, 06 Sep 2024 16:48:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0hyH2XBjz41D7 for ; Fri, 6 Sep 2024 16:48:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=troutmask.apl.washington.edu header.s=troutmask header.b=CRTkkzk1; dmarc=fail reason="No valid SPF" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.18.1/8.18.1) with ESMTP id 486GmrA4015317 for ; Fri, 6 Sep 2024 09:48:53 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 486GmrA4015317 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1725641333; bh=OEs9yFbCW/fWvrlDrXNrRWzzKECUqd76D3RiZTVbiO4=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=CRTkkzk16uuQsuIneNCVyJu/XVMf3YsCjNTU/ZKL1+ZF99xUklj+V9XE9XGJZZ7sF LlQ9fmI2dLLLpgEk3Wyb8UuXU/kn8x07EZxunU9G9L1dU9x9llMp9OgmUXaHgCYD9o mq5hCAk6b2g9IYE1aRLKjhTGNUep9xtkHTdHKDQ0Gc4lrc/OfjOKSk2na8JMJnNA+C LaGRaoqDjqzR+JFBmmcD92h7mLMpDFBhqEtb801m+tCP+Ph3HpX3KIiJlhkrIZv0NL /v87KJtg/m4mcJQ38wp8UNtmfxx1CVrsul1yf5WtvFwqtNaPnTI0WH26ACFGhXVrcN l58Tb3Z+Fb+WA== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.18.1/8.18.1/Submit) id 486Gmrvs015316 for freebsd-hackers@freebsd.org; Fri, 6 Sep 2024 09:48:53 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Sep 2024 09:48:53 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: New lock-order reversal Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF,none]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[128.95.76.21:from]; R_DKIM_PERMFAIL(0.00)[troutmask.apl.washington.edu:s=troutmask]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[troutmask.apl.washington.edu:~] X-Rspamd-Queue-Id: 4X0hyH2XBjz41D7 On Fri, Sep 06, 2024 at 08:54:21AM -0700, Steve Kargl wrote: > FYI (and return hackers to a non-language) > > Update my old system to circa Aug 10, 2024 top-of-tree > and rebuilts all installed ports. I'm now see a new > lock-order reversal while using openvpn. > Seems to be a known issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272573 -- Steve From nobody Fri Sep 6 16:49:48 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 4X0hzN39Rxz5VVRh for ; Fri, 06 Sep 2024 16:49:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0hzN2dmJz426q; Fri, 6 Sep 2024 16:49:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725641392; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fLK6ADGWgGhcjeXV7oDio2GR5LBuBIV9QvEgd486sPE=; b=s5I7JAZ8szS5Sj8bEeJH3OcLt+Xgy0t23MxhwjaoHe6Vn8IFtyNnBcdGtWMfxfwR7MyAmO yIFVRtTBI3rfw4tKtUXD3VXDirfeGt03CHvviv9W3MpLpAcvg3uhD0XTEm6rmzgffhye0E +mxuCELZtk3TQmJqj6qfFBv8KQQaP2ajbYnVb2xtaZ/2PzUocudcITG0pAkAHJRcQhuszS g6tHjFP268Qfj2Msfw1hWwxv4iKtrqnt5W5td1tf7ZA6ydlG6uiceWytaOlV/CSMcvZ1D4 gDTmKhSSCkS0orJ48CkK2+SgOyRTI7RIsL4bsejzAIysa8AfgYxZy7H8SPvR4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725641392; a=rsa-sha256; cv=none; b=AWdSD+gbuJ50evznc56aWJPhHnMzXIG+0LZuzxq9IKFimh2uJqp5GKrlPcGgggDmbxqow7 LlvnTCdhMSa0p4AakpUs98XHx+FBHqr2h3G/wvIJ5tYvdMi+QaYawn+0iGZFsoIf1bJN+B GJyJN9EVuVLBq04Ao6bJUn+1uOu4oajbxszwI4KOlEpMnWLaypd+B5pq2ZcSc8InOd9eqa tcAWpJ4NNnZUrwLFlMB0wtXi7ugVVAIPkMM6Pp6987VjghM9MjwHWNfir9AdUx+9RBe5Op aoq/Nc1nO7xPa/k9/lss7moaSaGFGp185umMWWW50batyuJd08Nr22dBSAU3lQ== 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=1725641392; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fLK6ADGWgGhcjeXV7oDio2GR5LBuBIV9QvEgd486sPE=; b=qp7tgwrfwUYq81nftyPYEeP2IzhKdvJMjMIxiBWc9FpsNl95u/9vQ+Syj/MXPpObcORIW9 GvhfjiAjto0hNWxMToDUP09QqTA2NZZZcmOM2SPKUJoGAYozreAGLqzdCDd0o3px+NBT/G Gmo4ZdQoQcdpr9uoWgJnp5tgIIDjxeb4NnJCBIh8Xlx9fkZNHjvgLq2JrZ1bZ2GtANezTk 854B2xU2DazAlugFzPXylusoJV8FeNiRZ3ci3gYqjVoPFlhmpwUlqL0hx7T7Z66Kb35STP YeXX+U+hwG5YlZj2iv0D99YtF2ys4v/V0vriKzp+G4u0nAC7xrRYV78DOvSzrA== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0hzN0wxlzThc; Fri, 6 Sep 2024 16:49:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 92AC23E6D7; Fri, 06 Sep 2024 18:49:49 +0200 (CEST) From: Kristof Provost To: Steve Kargl Cc: freebsd-hackers@freebsd.org Subject: Re: New lock-order reversal Date: Fri, 06 Sep 2024 18:49:48 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@FreeBSD.org> In-Reply-To: References: 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/alternative; boundary="=_MailMate_9C6D674F-29D9-450A-954C-B7353E708F39_=" Content-Transfer-Encoding: 8bit --=_MailMate_9C6D674F-29D9-450A-954C-B7353E708F39_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Steve, On 6 Sep 2024, at 17:54, Steve Kargl wrote: > FYI (and return hackers to a non-language) > > Update my old system to circa Aug 10, 2024 top-of-tree > and rebuilts all installed ports. I'm now see a new > lock-order reversal while using openvpn. > > lock order reversal: > 1st 0xfffff801e5482aa0 udpinp (udpinp, rw) @ > /usr/src/sys/netinet/udp_usrreq.c:1129 > 2nd 0xfffff80003510188 if_ovpn_lock (if_ovpn_lock, rm) @ > /usr/src/sys/net/if_ovpn.c:2118 > lock order if_ovpn_lock -> udpinp established at: > #0 0xffffffff80ba66fa at witness_checkorder+0x32a > #1 0xffffffff80b2d692 at _rw_wlock_cookie+0x62 > #2 0xffffffff80d45e4e at udp_set_kernel_tunneling+0x4e > #3 0xffffffff82a783a1 at ovpn_ioctl_set+0xe81 > #4 0xffffffff82a76df8 at ovpn_ioctl+0xf8 > #5 0xffffffff80c62179 at ifioctl+0x949 > #6 0xffffffff80bacd26 at kern_ioctl+0x286 > #7 0xffffffff80baca3d at sys_ioctl+0x12d > #8 0xffffffff8104b018 at amd64_syscall+0x158 > #9 0xffffffff8101d73b at fast_syscall_common+0xf8 > lock order udpinp -> if_ovpn_lock attempted at: > #0 0xffffffff80ba6f75 at witness_checkorder+0xba5 > #1 0xffffffff80b2c22c at _rm_rlock_debug+0x12c > #2 0xffffffff82a76e91 at ovpn_output+0x41 > #3 0xffffffff80d0e1ce at ip_output+0x150e > #4 0xffffffff80d45ad9 at udp_send+0xa69 > #5 0xffffffff80be56d1 at sosend_dgram+0x311 > #6 0xffffffff80be62b9 at sousrsend+0x79 > #7 0xffffffff80bec35c at kern_sendit+0x1bc > #8 0xffffffff80bec66b at sendit+0x1ab > #9 0xffffffff80bec4ad at sys_sendto+0x4d > #10 0xffffffff8104b018 at amd64_syscall+0x158 > #11 0xffffffff8101d73b at fast_syscall_common+0xf8 > I don’t think that’s new. It’s an order issue between if_ovpn establishing the UDP tunnel callback (which requires the UDP lock) and the normal traffic flow, where the UDP lock is taken, the tunnel function is called and that then takes the if_ovpn lock. I’ve had another look at this, and while I can probably avoid this for setting the tunnel function (basically by assuming setting it never fails or is already done, which is currently the case), I’m not happy with the only solution I see on the removal side (i.e. “don’t, just trust that the socket will be closed soon”). diff --git a/sys/net/if_ovpn.c b/sys/net/if_ovpn.c index ee097cfa24b3..322ac59e6dd0 100644 --- a/sys/net/if_ovpn.c +++ b/sys/net/if_ovpn.c @@ -390,11 +390,6 @@ ovpn_rele_so(struct ovpn_softc *sc, struct ovpn_kpeer *peer) has_peers = ovpn_has_peers(sc); - /* Only remove the tunnel function if we're releasing the socket for - * the last peer. */ - if (! has_peers) - (void)udp_set_kernel_tunneling(sc->so, NULL, NULL, NULL); - sorele(sc->so); if (! has_peers) @@ -636,18 +631,10 @@ ovpn_new_peer(struct ifnet *ifp, const nvlist_t *nvl) sc->peercount++; soref(sc->so); - ret = udp_set_kernel_tunneling(sc->so, ovpn_udp_input, NULL, sc); - if (ret == EBUSY) { - /* Fine, another peer already set the input function. */ - ret = 0; - } - if (ret != 0) { - RB_REMOVE(ovpn_kpeers, &sc->peers, peer); - sc->peercount--; - goto error_locked; - } - OVPN_WUNLOCK(sc); + ret = udp_set_kernel_tunneling(sc->so, ovpn_udp_input, NULL, sc); + MPASS(ret == 0 || ret == EBUSY); + ret = 0; goto done; Best regards, Kristof --=_MailMate_9C6D674F-29D9-450A-954C-B7353E708F39_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Steve,

On 6 Sep 2024, at 17:54, Steve Kargl wrote:

FYI (and return hackers to a non-la= nguage)

Update my old system to circa Aug 10, 2024 top-of-tree
and rebuilts all installed ports. I'm now see a new
lock-order reversal while using openvpn.

lock order reversal:
1st 0xfffff801e5482aa0 udpinp (udpinp, rw) @ /usr/src/sys/netinet/udp_us= rreq.c:1129
2nd 0xfffff80003510188 if_ovpn_lock (if_ovpn_lock, rm) @ /usr/src/sys/ne= t/if_ovpn.c:2118
lock order if_ovpn_lock -> udpinp established at:
#0 0xffffffff80ba66fa at witness_checkorder+0x32a
#1 0xffffffff80b2d692 at _rw_wlock_cookie+0x62
#2 0xffffffff80d45e4e at udp_set_kernel_tunneling+0x4e
#3 0xffffffff82a783a1 at ovpn_ioctl_set+0xe81
#4 0xffffffff82a76df8 at ovpn_ioctl+0xf8
#5 0xffffffff80c62179 at ifioctl+0x949
#6 0xffffffff80bacd26 at kern_ioctl+0x286
#7 0xffffffff80baca3d at sys_ioctl+0x12d
#8 0xffffffff8104b018 at amd64_syscall+0x158
#9 0xffffffff8101d73b at fast_syscall_common+0xf8
lock order udpinp -> if_ovpn_lock attempted at:
#0 0xffffffff80ba6f75 at witness_checkorder+0xba5
#1 0xffffffff80b2c22c at _rm_rlock_debug+0x12c
#2 0xffffffff82a76e91 at ovpn_output+0x41
#3 0xffffffff80d0e1ce at ip_output+0x150e
#4 0xffffffff80d45ad9 at udp_send+0xa69
#5 0xffffffff80be56d1 at sosend_dgram+0x311
#6 0xffffffff80be62b9 at sousrsend+0x79
#7 0xffffffff80bec35c at kern_sendit+0x1bc
#8 0xffffffff80bec66b at sendit+0x1ab
#9 0xffffffff80bec4ad at sys_sendto+0x4d
#10 0xffffffff8104b018 at amd64_syscall+0x158
#11 0xffffffff8101d73b at fast_syscall_common+0xf8


I don=E2=80=99t think that=E2=80=99s new. It=E2=80=99s an= order issue between if_ovpn establishing the UDP tunnel callback (which = requires the UDP lock) and the normal traffic flow, where the UDP lock is= taken, the tunnel function is called and that then takes the if_ovpn loc= k.

I=E2=80=99ve had another look at this, and while I can pr= obably avoid this for setting the tunnel function (basically by assuming = setting it never fails or is already done, which is currently the case), = I=E2=80=99m not happy with the only solution I see on the removal side (i= =2Ee. =E2=80=9Cdon=E2=80=99t, just trust that the socket will be closed s= oon=E2=80=9D).

di=
ff --git a/sys/net/if_ovpn.c b/sys/net/if_ovpn.c
index ee097cfa24b3..322ac59e6dd0 100644
--- a/sys/net/if_ovpn.c
+++ b/sys/net/if_ovpn.c
@@ -390,11 +390,6 @@ ovpn_rele_so(struct ovpn_softc *sc, struct ovpn_kpee=
r *peer)

        has_peers =3D ovpn_has_peers(sc);

-       /* Only remove the tunnel function if we're releasing the socket =
for
-        * the last peer. */
-       if (! has_peers)
-               (void)udp_set_kernel_tunneling(sc->so, NULL, NULL, NUL=
L);
-
        sorele(sc->so);

        if (! has_peers)
@@ -636,18 +631,10 @@ ovpn_new_peer(struct ifnet *ifp, const nvlist_t *nv=
l)
        sc->peercount++;
        soref(sc->so);

-       ret =3D udp_set_kernel_tunneling(sc->so, ovpn_udp_input, NULL,=
 sc);
-       if (ret =3D=3D EBUSY) {
-               /* Fine, another peer already set the input function. */
-               ret =3D 0;
-       }
-       if (ret !=3D 0) {
-               RB_REMOVE(ovpn_kpeers, &sc->peers, peer);
-               sc->peercount--;
-               goto error_locked;
-       }
-
        OVPN_WUNLOCK(sc);
+       ret =3D udp_set_kernel_tunneling(sc->so, ovpn_udp_input, NULL,=
 sc);
+       MPASS(ret =3D=3D 0 || ret =3D=3D EBUSY);
+       ret =3D 0;

        goto done;

Best regards,
Kristof

--=_MailMate_9C6D674F-29D9-450A-954C-B7353E708F39_=-- From nobody Fri Sep 6 16:53:01 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 4X0j343Hxtz5VVcn for ; Fri, 06 Sep 2024 16:53:04 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0j341Yp7z43V2 for ; Fri, 6 Sep 2024 16:53:04 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x143.google.com with SMTP id e9e14a558f8ab-39f49600297so8050505ab.1 for ; Fri, 06 Sep 2024 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1725641583; x=1726246383; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+aCLOkJOUyZjwv9vpmmoRI2vLk/oxFf8nNQ4jYTGxQs=; b=fmGZoBzRaixinsMo90c0nctst7Sn8knaNlvZ7DmvZTwGoizXPmOkeC+l3tMtyBSO6l 0F+mj9XUJMmgYGoR6HyC/VqSiJMnew88Ebot/EoHXFx1joSNJkizvK2VmIg0EQJ/GTwm ftgrWwUVVcgP0slrDgv/5iuEBePdSeEPmySa+XfB6P0wGCDqCiHE/LYRk1Xa+3bOU1g9 5EleITJzoGYAFgRvK5+h1Q8JiMLIWCRvjej7KqbERp9rx56GQcqq3Df8G7I5gMrfgp0D 9pq1K8cZyJb436K+ip3TTVEqbN5GNTqxPnM27J7rvqKNtGg8Gxi8hwCjyZtOcsJISL0m f1dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725641583; x=1726246383; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+aCLOkJOUyZjwv9vpmmoRI2vLk/oxFf8nNQ4jYTGxQs=; b=LwjQaSdgXllO9jnR2LLyfETmEYkwdbFCUk3HSw//8wPmHCbNFATSjxVkmrcdlMCjsq pWAITG1x6+ZUYoh2W+cOSbLC4Nmb/EfYlVeobHFpOS/9Kqn9TkeEJvQEgwFkj4xca6qQ yMwRFpaSNc68mS6WN3TlVHuJTvHrs1ag17YIv54B1/pfr72NyekCp204Ah2A7fk4pUP9 E9z1+mQwyU/hSLRW9Eq0/NHGv+8dX3xaZkmAfA0jv4HKbrYeqryT0h0oLzechH4L/mTG 5hrQBATlR0QpWdijpBQoR9zLLr+iIbA5JB1JVuv+OltRlOo6kvHDSEaJSNu2nX3FRMco cu0A== X-Forwarded-Encrypted: i=1; AJvYcCVJz75Qn5LLcGIzwJa9CAwKN/fy5dPFTfak2us+f4+S93ZNEKI77PGIcvMFU3t2uhr9qIS5WJ89OUDF+Ji9j4M=@freebsd.org X-Gm-Message-State: AOJu0Yy5fUNIPfyD2EsgVw2jALEMgeMu58kxuyPhocWKdLaW56smtX3G YMVxvlzo7SufmzM66A1LvxCEoJ3hLs/1pZbxSyZ4xeXdyQhOulGMvmQT9NOsRTU= X-Google-Smtp-Source: AGHT+IFtG8qVDuvCQsY3g7Cj/aeizuBDn20Q3tP00a/23sJuRgyYOksJiAkpc9Ea1PcHHednAAOJ0g== X-Received: by 2002:a05:6e02:19c6:b0:39f:b5e7:93f3 with SMTP id e9e14a558f8ab-39fb5e79519mr107127215ab.20.1725641583116; Fri, 06 Sep 2024 09:53:03 -0700 (PDT) Received: from mutt-hbsd (174-24-73-190.clsp.qwest.net. [174.24.73.190]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-39f6ebe5ba6sm18638195ab.13.2024.09.06.09.53.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Sep 2024 09:53:02 -0700 (PDT) Date: Fri, 6 Sep 2024 16:53:01 +0000 From: Shawn Webb To: Baptiste Daroussin Cc: Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="begvzjljlzqbr65o" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0j341Yp7z43V2 --begvzjljlzqbr65o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 06, 2024 at 09:19:44AM UTC, Baptiste Daroussin wrote: > On Thu 05 Sep 12:09, Alan Somers wrote: > > By now I expect that most of you have seen the long list of new > > security advisories that just came out. Strikingly, all were the > > result of memory handling errors. And none of them wouldn't have > > happened if their respective programs had been written in a > > memory-safe language. > >=20 > > In fact, of all the C bug fixes that I've been involved with (as > > either author or reviewer) since May, about three quarters could've > > been avoided just by using a better language. > >=20 > > The real takeaway here is that C is no longer sufficient for writing > > high quality code in the 2020s. Everyone needs to adapt their tools. > > Programmers who don't will increasingly come to resemble experimental > > archaeologists, i.e. people who learn flintknapping to "keep the > > knowledge alive". Such people are valuable, but definitely niche. I > > for one don't want my career to go in that trajectory. > >=20 > > To summarize, here's the list of this week's security advisories, and > > also some other recent C bug fixes of my own involvement: > >=20 >=20 > Jumping on this one, I think at least that is my understanding from the p= revious > threads, that using some rust has not been rejected, so keeping discussing > at length and trying to force convince people will not lead to anything t= hat > would make progress on the rust integration process. >=20 > On the other side there have been many "work to do, problem to solve" tha= t has > been raised to allow to make it happen, so far I have seen none of the ru= st > people actually trying to work on solving those issues, I would have expe= cted > now to see patches, design proposals, questions and so on to move forward. >=20 > For the people who want to see rust usage in base, it is time to start the > actual hard part if you don't want those threads to be seen as "yakafokon= " (as > we say in french, I don't know if there is an equivalent of it): > - make a plan > - write patch and poc on how to integrate to our build system > - discuss with the people who volunteered to help on the build system, on= the > release engineering, or on the packaging side. > - create AND lead the working group to make this happen. Hey Baptiste et al, I'm including the email I sent to this list last week below. Unfortunately, due to having to clean up some fraudulent financial activity last weekend, I didn't make any progress. I'm hoping to split my time this weekend between working towards my OSCP cert and this work. =3D=3D=3D=3D BEGIN ORIGINAL EMAIL =3D=3D=3D=3D So, to those thoughts, in list form (in no particular order): 1. Use of Rust compiler toolchain support will be for userland components in an opt-in fashion. Meaning, all userland components written in Rust will be optional. 2. It does not make sense to perform a vendor import of the Rust compiler toolchain and standard libraries. All Rust code in the src tree must be built from an external toolchain. 3. I believe the notion of an external toolchain could be abstracted such that we can support any optional userland component written in a language supported by that external toolchain. This would imply that other alternative languages could be supported with minimal work (Zig, TypeScript, Python, Java, etc.) 4. We could provide auto-detection mechanisms for determining which external toolchains are available, their language support, etc. The initial proof-of-concept would likely be limited to Rust to save on time and complexity. 5. As the work matures, and perhaps as a requisite for eventual inclusion, we could land support for more than Rust. This might be a step too far, but hey, it's one of the thoughts I had. 6. So all of this wrapped up means that: A. This is NOT a call to rewrite everything in Rust. This work will only permit NEW, OPTIONAL components to be written. B. Other languages/toolchains/ecosystems could be supported, not just Rust. C. Initial focus is on userland components. Rust in the kernel is out of scope for this initial proof-of-concept. D. I would like to see Rust in the kernel. That would be a good next area of focus once userland support reaches some level of maturity. My first goal will be to get a better understanding of src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also study your work, Alan. I really appreciate the time you have taken. I might reach out to you and Warner directly for further questions. =3D=3D=3D=3D END ORIGINAL EMAIL =3D=3D=3D=3D I feel like I should elaborate on item 6.A a little bit. It would be cool to see some utilities rewritten in Rust (bhyve would be a great candidate), but my work will focus only on new (completely optional) utilities solely to get some momentum going. I should also note that this likely will expand FreeBSD's existing notion of an external compiler toolchain. If I understand correctly, though, the existing external toolchain support targets C/C++ code. I'd like to expand that to support !(C || C++), beginning with Rust. So, for the community reading between the lines, I'm hoping to make this support languages/ecosystems other than Rust. That includes Ada/SPARK, Python, Java, or even Brainfuck for the true masochists. ;-) I'm starting with Rust, though, because that's what appeals most to me. Hopefully, as time progresses, others can expand that work even further for those additional languages/ecosystems. ${LIFE} does tend to be a bit chaotic and unpredictable at the moment, so I can't promise timeframes--which is why I usually use the word "hope" when talking about what I would like to accomplish within a given weekend/month/etc. Let's see how this goes. :-) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --begvzjljlzqbr65o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmbbM2YACgkQ/y5nonf4 4fpZFBAAmqcOkKJ49CdgSKG6mUHu1N3iIowY5KOcE7921LgzVIK8RkqO33bEr8n/ vgFp4JDxdWksWrRi7Wlo/XLvOXwrLggEkLkcWA2I9no0wXSP3kIOt4IaOCKMP/+Z vvwf2fGLb0kW2PLacnAhDKvMqKQOjz5DIohHsL1v5K49QAcAUXj8Q8RNfP5siqE7 A6kekZrkPaH7yk8h8HzSs5YVUYoRPSUkBrme67ZcrNw6OhE733tqrqUgz3jxVqHY Oh9pF6UOKn/EWMZK/YWRo+dRtTtM0s3HtNyOdH62Ijn5efI6Ot2aG7HkxD50w2gS NB6hGjhcyRNibZXlavhSitlabQ4C0bdPre59pEVHg9W9omS+p3jTkL38xrurPEVA NxTdU9nFpujx5mh6sIUsXgZao2Vxz5VcrFzrERU/uCTkD+2rAHn/Cx+SV/07pqom w58PFztzhU9Wj4gzmCAAAW9vb8mRbkr+7gLPFq0npzcfjuSDJEUiQJJN8yjLkMrn 3+VVUBvGJ/yhVGE/vpLvOlVclqsLwAGG0Qu4jBBNwLPRcOj0MpMG+HPO7WIk+3n6 6oPv5JgqwC7jt99mGBiipIqXj1i3ilRNtpLWHDyVQorkyhqDphvwu0OGGS6Wlv0y xxTXQBwNUHJP0aRvwUHYfADC4JWNl0yxDCrJQoBhTBqbMm5OH+o= =F3XK -----END PGP SIGNATURE----- --begvzjljlzqbr65o-- From nobody Fri Sep 6 17:15:46 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 4X0jYJ3jQLz5VXny for ; Fri, 06 Sep 2024 17:15:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0jYJ2WvZz46lk; Fri, 6 Sep 2024 17:15:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.18.1/8.18.1) with ESMTP id 486HFkHR015532; Fri, 6 Sep 2024 10:15:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 486HFkHR015532 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1725642946; bh=51m7e+YwK30hv2Lrx5UOab3eqWaSFjH4vSlrfOoODpM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=QafYIXG0US0ZT5oxDMoVpXL/78+kHyoAWq+W3izHup1NV+RGXImznmVGabQ9nITXh VHId3hwm7wZiSKor/2zNHtX+KThWuLU8hkumGAXr4cv8paEij8Pon9Ens5dCiYeZM9 gGdRT2sOgHkNF39NwjT77y2zEo5nQObNiAclndkc+EzhM+w+tkn2TgLzBOwN3XEVVh oFnT+95sdoyA7k+vMNtLT0tGWelW0odadTjsSuwmSS7i5D44L+oPo1C+LxAcTEkFpA 01gklgZScyJNEtAkdBBtuSOiF5WGNFQBMubfCS6uXj1hF0UjGZpxX6yX9UeNVRhv2n BICtVYkxl9v4w== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.18.1/8.18.1/Submit) id 486HFkBE015531; Fri, 6 Sep 2024 10:15:46 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Sep 2024 10:15:46 -0700 From: Steve Kargl To: Kristof Provost Cc: freebsd-hackers@freebsd.org Subject: Re: New lock-order reversal Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@FreeBSD.org> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@FreeBSD.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4X0jYJ2WvZz46lk On Fri, Sep 06, 2024 at 06:49:48PM +0200, Kristof Provost wrote: > Hi Steve, > > On 6 Sep 2024, at 17:54, Steve Kargl wrote: > > FYI (and return hackers to a non-language) > > > > Update my old system to circa Aug 10, 2024 top-of-tree > > and rebuilts all installed ports. I'm now see a new > > lock-order reversal while using openvpn. > > (trace elided) > I don’t think that’s new. It’s an order issue between if_ovpn establishing > the UDP tunnel callback (which requires the UDP lock) and the normal traffic > flow, where the UDP lock is taken, the tunnel function is called and that > then takes the if_ovpn lock. Yeah, I should have looked at bugzilla. There is a report of the LoR. > I’ve had another look at this, and while I can probably avoid this for > setting the tunnel function (basically by assuming setting it never fails or > is already done, which is currently the case), I’m not happy with the only > solution I see on the removal side (i.e. “don’t, just trust that the socket > will be closed soon”). Thanks for the patch. I'll add to my kernel when I rebuild it. Unfortuantely, I have way too little understanding about locking within the kernel to be of much help. -- steve From nobody Fri Sep 6 17:49:40 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 4X0kJl4Nflz5VM7d for ; Fri, 06 Sep 2024 17:49:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0kJl2Yd6z4D5l; Fri, 6 Sep 2024 17:49:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-5e1ba05bf73so62137eaf.3; Fri, 06 Sep 2024 10:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725644998; x=1726249798; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=3wpDSDFs9gN3NgvDjJK/S1VbZXMmLh8ylxZwEYj6ahk=; b=eDwFvpzOHwOslYepUUGlcn/sZbLqmXID8kJd4rvgjV+7vF/QD07LwereczXo9xUg97 Fhy+pwiwDaZDzh6D49b/yxycDDGkSvyHDCLsMu9pS9XMmSGKVW8H/BnyXo9mJ0T2uJn7 0sTzym5SwZPQBfg11LTwUcWP7+89mf2m+GpRwdlIm9bGviqfJbSTOy/rO9KHE/XPrfZB U7+3lZuA9/npcEFkqbuR65tT/7Q/ii1HZ/posHvNNsYGVMKnCRw6l7ZaGZ8jH2dgEA6a ZxvRFWOBTS8JLW7z0zJ2G6NDYEhVqA89SdIcroop2OHH0HmO6SS0hTY+xz/IfSvoER0I O9rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725644998; x=1726249798; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3wpDSDFs9gN3NgvDjJK/S1VbZXMmLh8ylxZwEYj6ahk=; b=iWMPKM6fe5B5bmZiwvqFDQC+bPSluHfGDy9tec9mR6OneUYr765voghi1v11NAVT5H kcoDLJeKDmgIQfLQNaLO2BcHWKg4kw7Q0EeD81Q8F3JZwd2dAsUCs7R4AfZgvk3tjaq7 I0HMqVtscfXQlQvC/8oVaEAy1jD4VIlGS7W0KCp75+d39k/2Mpko09WGjFgsN7c0vUfg q5by+1pBJQrWAmUlS75Bd73DOMHRUkUW3wkCqs6IxkQI28TQR++t6VMgD3HJAJu0pNo8 0trKJnFSVCoythS44Tax2Txz5MT9uQmBRIL7zsxPXl7f57O0rYHIE8+JcuPsv1MhKdhD qp3g== X-Gm-Message-State: AOJu0YyOfkvPopvbVCxpv6JXgxkApOIx1Nbias4V2C8uP4FoyKbfe5JE U6395mwPKCMKg2gXu5e5SFHlvxDDOfjwUHfo7/vlYaZPGuCuPq1OfV8bTPnaPPQ= X-Google-Smtp-Source: AGHT+IEJvwasChx0m6uB3NpaSqELDwUscbiA30ROHV/T9Yse1majJQEa9PW2jk2dbYfLoGz/grvnrQ== X-Received: by 2002:a05:6870:818b:b0:277:e868:334f with SMTP id 586e51a60fabf-27b9dd769a5mr68985fac.34.1725644997783; Fri, 06 Sep 2024 10:49:57 -0700 (PDT) Received: from smtpclient.apple ([192.154.196.243]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-27b73a4264fsm863060fac.9.2024.09.06.10.49.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Sep 2024 10:49:57 -0700 (PDT) From: Enji Cooper Message-Id: <389B68AC-D6F5-47F9-BF01-D3A96A124AC7@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: The case against C in the '20s (was "The Case for Rust (in any system)") Date: Fri, 6 Sep 2024 10:49:40 -0700 In-Reply-To: Cc: FreeBSD Hackers To: Alan Somers References: X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0kJl2Yd6z4D5l --Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158 Content-Type: multipart/alternative; boundary="Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF" --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 5, 2024, at 11:09=E2=80=AFAM, Alan Somers = wrote: >=20 > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. >=20 > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. >=20 > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. >=20 > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: First off, I wholeheartedly agree and enjoy Rust, even though I also = acknowledge the immaturity of the Rust ecosystem. That being said=E2=80=A6 - I personally think us switching from standard C to modern C++ in = _certain_ components could also reduce the likelihood of these issues = occurring in the future. - Using Coverity or other SA tools like llvm scan-build (enabled in = CI/triggered by Phabricator?) might have also helped reduce the = likelihood of this occurring. I know I=E2=80=99m diverting the topic and this has probably been hashed = out already in the other threads, but I think it=E2=80=99s worth = considering as an alternative to binding Rust to FreeBSD (in Rust=E2=80=99= s current state/at its current maturity). Thanks for bringing up this topic (and others for discussing this at = length). This is something that=E2=80=99s been important as of late in = many security circles (mitigating/reducing "toe stubbing" on common = security issues). Cheers, -Enji PS I am having to deal with the whole rolling upgrade bootstrap problem = with lang/rust at $work again going from 1.7x.y to 1.80.1. It=E2=80=99s = a large resource drain having to rebuild lang/rust from scratch on = target systems because our builder nodes don=E2=80=99t support running = the prebuilt rust binaries :(. I acknowledge that=E2=80=99s a = =E2=80=9C$work=E2=80=9D problem, but=E2=80=A6 it=E2=80=99s something = that $work frankly doesn=E2=80=99t run into with other languages like = golang, Java, perl, python, etc.= --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 5, = 2024, at 11:09=E2=80=AFAM, Alan Somers <asomers@FreeBSD.org> = wrote:

By now I = expect that most of you have seen the long list of new
security = advisories that just came out.  Strikingly, all were the
result = of memory handling errors.  And none of them wouldn't = have
happened if their respective programs had been written in = a
memory-safe language.

In fact, of all the C bug fixes that = I've been involved with (as
either author or reviewer) since May, = about three quarters could've
been avoided just by using a better = language.

The real takeaway here is that C is no longer = sufficient for writing
high quality code in the 2020s.  Everyone = needs to adapt their tools.
Programmers who don't will increasingly = come to resemble experimental
archaeologists, i.e. people who learn = flintknapping to "keep the
knowledge alive".  Such people are = valuable, but definitely niche.  I
for one don't want my career = to go in that trajectory.

To summarize, here's the list of this = week's security advisories, and
also some other recent C bug fixes of = my own involvement:

First = off, I wholeheartedly agree and enjoy Rust, even though I also = acknowledge the immaturity of the Rust = ecosystem.

That being said=E2=80=A6
- = I personally think us switching from standard C to modern C++ in = _certain_ components could also reduce the likelihood of these issues = occurring in the future.
- Using Coverity or other SA tools like llvm = scan-build (enabled in CI/triggered by Phabricator?) might have also = helped reduce the likelihood of this occurring.

I know I=E2=80=99m = diverting the topic and this has probably been hashed out already in the = other threads, but I think it=E2=80=99s worth considering as an = alternative to binding Rust to FreeBSD (in Rust=E2=80=99s current = state/at its current maturity).

Thanks = for bringing up this topic (and others for discussing this at length). = This is something that=E2=80=99s been important as of late in many = security circles (mitigating/reducing "toe stubbing" on common security = issues).

Cheers,
-Enji

PS I am having to deal with the whole rolling upgrade bootstrap = problem with lang/rust at $work again going from 1.7x.y to 1.80.1. = It=E2=80=99s a large resource drain having to rebuild lang/rust from = scratch on target systems because our builder nodes don=E2=80=99t = support running the prebuilt rust binaries :(. I acknowledge that=E2=80=99= s a =E2=80=9C$work=E2=80=9D problem, but=E2=80=A6 it=E2=80=99s something = that $work frankly doesn=E2=80=99t run into with other languages like = golang, Java, perl, python, etc.
= --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF-- --Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmbbQLQACgkQGpE5DjPs NJiwvw/9G4tos0ditqxV4IXKzhV8LRNJr+WCcrUbN9tFVm12b7UEJH2LpsgAumUI xlaBcoUQBhG88+XRUIcYwwIHdxHzG6w5doQ+Fs7IlJZ85rDUAF+UutxftYPfy9PA QXgvqrXNLu4hu+ccRahIdHemB6T2UnicWZklDUYn8lcFAohTWko232avJxNw4Saf EIFWVplEtYF8xXdDRbqdsGEnzSATqANKV1fkUoMy7g4pdn8Er9271isk2R2WHKmB Ojcomwa+PMTIzPUwHQmoDefdPz61rP0nSdEvtbqh3cEmvgjhtHDuKPAbKq1//tpY fCBZZ3PdJIBM6XVpLNNkqZqsAezXbIYayn5XP97puBwC1OR8Jdi9R3xRhgwbsk+L Hofsr+bLNt7brq20spIfaDKLv4wQeU6geAF7jMZwd8gK67sIrvPsD3697eWbtera XzP1DEm0QlLWXIXy+CjTcC8pNfEWBDCCD1RlH3++yYeNAE/Ec+SCev6CXJg9M+12 8BYuBsLXfLo+LWcPkPu0UGtrBswl1HsSCRyTqgocC7ai6/SZA9YoGs7ZW7qUfKZZ mvZLKULFoPfohT5XAl7O/vS775tfN6rw17lFRvz5Lg8GdunyRFfl+OcLuEdAeIrs N7yugngNOALa7QJWUf0IkW4CT+AV3Q8J/Hd8H/rj3DiMKJi7kFc= =/Xfz -----END PGP SIGNATURE----- --Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158-- From nobody Fri Sep 6 18:25:12 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 4X0l5g3Ytmz5VQg6 for ; Fri, 06 Sep 2024 18:25:27 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0l5f6plfz4Ryy; Fri, 6 Sep 2024 18:25:26 +0000 (UTC) (envelope-from eischen@vigrid.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (mobile-166-196-106-050.mycingular.net [166.196.106.50] (may be forged)) (authenticated bits=0) by mail.netplex.net (8.18.1/8.15.1/NETPLEX) with ESMTPSA id 486IPN3N010023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Sep 2024 14:25:23 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 06 Sep 2024 14:25:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Daniel Eischen 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Fri, 6 Sep 2024 14:25:12 -0400 Message-Id: References: <202409061600.486G0UrR046040@critter.freebsd.dk> Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers In-Reply-To: <202409061600.486G0UrR046040@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPhone Mail (21G93) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] X-Rspamd-Queue-Id: 4X0l5f6plfz4Ryy > On Sep 6, 2024, at 12:01=E2=80=AFPM, Poul-Henning Kamp wrote: >=20 > =EF=BB=BF-------- > Daniel Eischen writes: >=20 >> And back in the 80s, Ada was supposed to be the answer for safe coding la= nguage. >=20 > And it seems to have done quite well. >=20 > Show me any other language which has developed something like SPARK ? >=20 > I think Ada's problem was that it was a "DoD language" so everything was > priced 10 times what it should have been, (because why not when you can > get away with it...) I am not disagreeing, I still develop in Ada to this day as a DoD contractor= , but it is a constant struggle to find new talent that wants to develop in A= da, as well as convincing management that we should still be using Ada becau= se of the former. 38 years as SW engineer, I always tell management, any good SW developer sho= uld be able to pick up a high-level language without much problem; it's the "= I don't know that, I don't want to learn it" attitude that is the problem. I= f we have to start using rust, so be it, I just don't want it to be just ano= ther new shiny thing that becomes technical debt in 5 years. -- DE= From nobody Fri Sep 6 19:28:49 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 4X0mVs2KVmz5VYs2 for ; Fri, 06 Sep 2024 19:28:53 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0mVr74V9z4pTm; Fri, 6 Sep 2024 19:28:52 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725650930; x=1726317596; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=wsGY+8tBKCoahmdz1TROgfdph/RNIWg5XrgTNwpncyY=; b=M4OM1yfOyei3PhUPTFimJ5TGZDLyRs//1EFQNW9wh72iWgeoACMH+BicIBEwYSONpuKBU/mq tQq+zt9foah23jYvI1wHFh2BsfF5GFgp2aYN1VaMBBEZ3fsM4r3UDa5qwuBtmsHJKggOpUocgj cOy1L66r8uMqyY0Tl0sCwWm69UdSrVoidXNER+TnBPpxfThQIvXEPrZjhRdpldF0ATJGqxv0j6 nStwFgsJyw4AlZ7vURMomek5XoTLQrIfl37MdgNjb1OMLY7mEaLPmRWhIidXodpNGPoKMxTj5k t/dTRvYnJFVM/ONU1LbPuzYRJIgbIHF58uuD6TJfDDUSvaWw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725650930; x=1726317596; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=wsGY+8tBKCoahmdz1TROgfdph/RNIWg5XrgTNwpncyY=; b=kb8ez7g2X5P143nvH55jNcR9cdyVnvBOqIH2bzRzyqv6UJ2QMYiL1M2jKqwasIXvpyaZ/z/t iZjwvISaxDUxDA== Date: Fri, 06 Sep 2024 21:28:49 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "Poul-Henning Kamp" Cc: David Chisnall , Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240906192849.TISsX21Q@steffen%sdaoden.eu> In-Reply-To: <202409060725.4867P3ul040678@critter.freebsd.dk> References: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> <202409060725.4867P3ul040678@critter.freebsd.dk> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X0mVr74V9z4pTm 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 Poul-Henning Kamp wrote in <202409060725.4867P3ul040678@critter.freebsd.dk>: |-------- ... | Danish dynamite!! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Sep 6 20:48: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 4X0pH71YVZz5VxLF for ; Fri, 06 Sep 2024 20:48:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0pH65GYGz40k7; Fri, 6 Sep 2024 20:48:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 486KmdWO013892; Fri, 6 Sep 2024 23:48:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 486KmdWO013892 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 486Kmceh013891; Fri, 6 Sep 2024 23:48:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 Sep 2024 23:48:38 +0300 From: Konstantin Belousov To: Daniel Eischen Cc: Poul-Henning Kamp , Antranig Vartanian , Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: References: <202409060836.4868agnQ042462@critter.freebsd.dk> <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4X0pH65GYGz40k7 On Fri, Sep 06, 2024 at 09:16:26AM -0400, Daniel Eischen wrote: > > > > On Sep 6, 2024, at 4:37 AM, Poul-Henning Kamp wrote: > > > > -------- > > Antranig Vartanian writes: > > > >> My point is: yes, we do need better languages. Yes, we do need memory-safety > >> and better tooling. But is Rust the answer? > > > > Rust is what all the cool kids run right now, which they will deny, > > claiming that Rust Is Simply Superior in replies to this email, > > despite this prediction. > > > > But as I said in an email a couple of days ago: We should not > > anoint some particular subset of programming languages or other. > > > > We should answer the question "What is FreeBSD?" in a way which > > does not contain a very short and controversial list of "approved > > programming languages". > > > > A pkg-based FreeBSD will allow the Rust people to write good code > > for FreeBSD in Rust, and C, C++, Go, Lua, OBERON or Ada can freely > > compete with them, without causing year-long slug-fests on the > > mailing lists. > > > > And if the INTERCAL people want to write FreeBSD kernel code in > > INTERCAL, they get to maintain whatever it takes for their > > compiler to grok the interfaces to the kernel, likewise for > > any other language. > > > > Poul-Henning > > > > > > PS: I'm disappointed you did not mention Ada with SPARK. > > +1 > > And back in the 80s, Ada was supposed to be the answer for safe coding language. Isn't SPARK license non-FOSS and requires payments? From nobody Fri Sep 6 20:51:44 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 4X0pLW6MpJz5VxVk for ; Fri, 06 Sep 2024 20:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0pLW3DVdz4214; Fri, 6 Sep 2024 20:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B4A778928B; Fri, 06 Sep 2024 20:51:45 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 486KpiFD048978; Fri, 6 Sep 2024 20:51:44 GMT (envelope-from phk) Message-Id: <202409062051.486KpiFD048978@critter.freebsd.dk> To: Konstantin Belousov cc: Daniel Eischen , Antranig Vartanian , Alan Somers , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: <202409060836.4868agnQ042462@critter.freebsd.dk> <102A9A46-D577-4651-8418-5E7946EA30A0@vigrid.com> 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: text/plain; charset="us-ascii" Content-ID: <48976.1725655904.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 20:51:44 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X0pLW3DVdz4214 -------- Konstantin Belousov writes: > > And back in the 80s, Ada was supposed to be the answer for safe coding= language. > > Isn't SPARK license non-FOSS and requires payments? I have no idea. My association with Ada is retrocomputing: https://datamuseum.dk/wiki/Rational/R1000s400 = -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Sep 6 21:07:11 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 4X0phM4HXpz5W08g for ; Fri, 06 Sep 2024 21:07:15 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0phM0b6xz456C; Fri, 6 Sep 2024 21:07:14 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725656833; x=1726323499; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:author:from:subject:date:to:cc:resent-author:resent-date: resent-from:resent-sender:resent-to:resent-cc:resent-reply-to: resent-message-id:in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=zMSi5FmF3fjAdFlT7bxGDte+60wKXckDBd3ckMCxvws=; b=BNGiugj0io6o1bhuaNUzTp2h6OQKl53f78uCcQaSvNnnb30CoJOvqH2HiP/ZrTnQj+TE/EGc oqdeEVQ+gLGlkT6zHeWxCp3zyRE1UGaR/mvoJF4C5m8a1wUQogIq5RDJtR6g8o5a9EiuHYSCP5 FDxYhC9ib2ZPE5CW+kGoksTs+XH26RZde0vAJqRvx9l7QTIwCBb6gaShZjvBivZvnzMR5sZBPe +DhxcZ7G8eusTzof5R+Hi6FuKngLxT+mbsOQWkLOqrwj4Fl44dq3HfK+x/zmx5w2xTEamB7aUN X1MHwP8/LjhgPo+8Mc69DsnDDkwFuwuHk6gHq5XKfu+5FGXw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725656833; x=1726323499; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:author:from:subject:date:to:cc:resent-author:resent-date: resent-from:resent-sender:resent-to:resent-cc:resent-reply-to: resent-message-id:in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=zMSi5FmF3fjAdFlT7bxGDte+60wKXckDBd3ckMCxvws=; b=d7Z8EMpWVSLf92e6oe+zZP7jNweIshQFK43444ASQba/xdU5/40+WiczE7vz3GCVvnyJvIGG Up4OmtSdb+gNAQ== Date: Fri, 06 Sep 2024 23:07:11 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Alan Somers Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240906210711.RUo97_0A@steffen%sdaoden.eu> In-Reply-To: References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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/mixed; boundary="=-=A8lNZqNxebGArEOA2g_DEM4bbUcV8TbYFNf0=-=" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X0phM0b6xz456C This is a multi-part message in MIME format. --=-=A8lNZqNxebGArEOA2g_DEM4bbUcV8TbYFNf0=-= Content-Disposition: inline Content-ID: <20240906210711.oNWaQ7R3@steffen%sdaoden.eu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alan Somers wrote in : |On Thu, Sep 5, 2024 at 4:51=E2=80=AFPM Steffen Nurpmeso wrote: .. |> ske-89@pkmab.se wrote in |> <202409052313.aa18097@berenice.pkmab.se>: |>|Alan Somers wrote: |>|> In fact, of all the C bug fixes that I've been involved with (as |>|> either author or reviewer) since May, about three quarters could've |>|> been avoided just by using a better language. |>|... |>|> To summarize, here's the list of this week's security advisories, and |>|> also some other recent C bug fixes of my own involvement: |>| |>|After checking several of these examples, I'm wondering what the code |>|would have looked like in some "better language", where those bugs would |>|have been avoided? |> |> Examples. I find the absolute opposite after checking four. ... |I'm having trouble following your English, but you seem to be missing |the point. The point is not whether the bugs can be fixed in C; of |course they can, after all we just did. The point is that safe |programming languages make it nearly impossible to create the bugs in |the first place. For example, a language that uses RAII everywhere |makes it nearly impossible to allocate a structure without |initializing it. Nearly impossible to leak memory, too. C++ also has automatic constructors. Scoped instances get automatically destructed, too. (To me this is all horrors, including Stroustrup's very own, iirc, first-time-init-switch injection (aka inject instances of a class via .h into each compilation unit where they are used), as you then get those linker sections dtor and fini etc etc. You know all that.) Yes, you know all that. No, so no, and then, i have not looked, a lot of the errors stem from optimization away things until you really really know, and this then leads to logical errors. That of course goes away with "RAII" (referring to that commit "of yours"). But i note that RAII can require more object states, possibly new object members even to be able to differentiate them, even though that could be not more than a bit. (And that possibly all the way up to a super object in case of "real object" hierarchies.) More data all along the path, i have definetely seen that. In C++ .. and plain C, but not automatically there, of course. *I* am happy that i do not have to go Rust, i do not like it; then rather C# (i had to go JAVA ~26 years ago). But in fact i do like the blood sweat and tears of raw C without any help, no automatic ctors, dtors, etc etc. I only feel sorry for things like what PHK just said, or what Dennis Ritchie famously said in 1988. The ISO C standard is a real mess, despite all the misses (struct aligning, packing, even endian layout (oh!); bit enumerations (henceforth totally shot to death since members of different enums may no longer be used together in | etc operators, leaving you with only preprocessor possibilities for bit flags .. or a tremendous number of casts) noted already, desasters like static_assert pre-C23; ISO C++ should always simply have been built upon ISO C imho, and the C++ static_assert was sane from the start. And so forth. But some basic types could be mentioned as well, now that you have mentioned Vec. Ie, monks have to (work work work and) carefully and consciously rake the sea into the gravel as a kind of contemplation. Slow food and such that is. And that is a goal i like. Ok business is the other thing, they will finally abolish life on earth for sure, that was known 170 years ago already, but *you* have to make a living, i understand that. And in a rapid application development environment, surely already or soon also AI-assisted, with module-drag-and-plug and live-compilation, this seems strange .. and surely is. Yet -- in such an environment, there are plenty of hints and tools to prevent errors like surely that strnlen() thing. You do not need Rust for that, in my opinion, i would think you need a good utility library with graceful test coverage, and strictly stick to usage of such tested utilities when you program your own thing. New ISO C23 even has integer overflow functions. Today the new TZ came into FreeBSD, which introduced bugs because it replaced its built-in functions which provided the same facilities (correctly) with usage of those. |>|/Kristoffer Eriksson |> --End of <202409052313.aa18097@berenice.pkmab.se> |> |> In support for that swedish hm virgin, yes, sweden is not a clean |> country for sure. | |Again, I don't know what you mean. But it looks like a personal |attack to me. Please try to keep your discourse on the public mailing |lists respectful. I cannot understand how you come to the conclusion the above was addressed to you; it referred for example to the attached picture. |-Alan --End of --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) --=-=A8lNZqNxebGArEOA2g_DEM4bbUcV8TbYFNf0=-= Content-Disposition: attachment; filename="OvershootDay.jpg" Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <20240906210711.qwc6P-Iv@steffen%sdaoden.eu> /9j/4AAQSkZJRgABAQEBLAEsAAD/4Rp6RXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAfAAAAcgEyAAIAAAAUAAAAkYdp AAQAAAABAAAAqAAAANQAAAEsAAAAAQAAASwAAAABQWRvYmUgUGhvdG9zaG9wIDIyLjIgKFdpbmRv d3MpADIwMjM6MDE6MDQgMTQ6MzE6MDMAAAAAAAOgAQADAAAAAQABAACgAgAEAAAAAQAAA+igAwAE AAAAAQAAAygAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABIgEbAAUAAAABAAABKgEoAAMA AAABAAIAAAIBAAQAAAABAAABMgICAAQAAAABAAAZQAAAAAAAAABIAAAAAQAAAEgAAAAB/9j/7QAM QWRvYmVfQ00AAf/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAIEAoAMB IgACEQEDEQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVUkkklOH1Drt+P1oYDX42PRRVXkXnILjbc2x1jDX0+mr6b6W0e/wDnv0llNPo/4RAr +vPSnYxyH031gNc/afSJ2tx3dTrduZe+r9NjM9lfqer6n896X84tXqVOTZZQ/HxsfIfUXFtl/NTi NrbKvaXf19rq1WGNYcd9Luj4wra8Wsp3sLHWbhutj0drLNpdZ6n01KOChY/51MZ4rNH8Grl/XGir 1mUYd1ttTixge6tjbCy7Fw8hrH+pY5rqn59H89VX6iLd9bMSjH+024mU2l112NU4Nrf6l1LnU/Z6 21XPd6mTfVZRi+p6fqWs/M/Rb7G3OfayenUMYX/pHl7XGHPY99jfYz/Rb/8AjPQ/0aC7G6hkfZHZ GBU04trby0Www2ODvWuFDWOa59VlljqvVs/nv0/84lUO3n6lXLuf8Vr9e+sOZgZf2ag4uN6WIc2x +c4tFgDiz7Lj+m5rfUZs/TXfpvS9Wj9Bb6ic/XTBrafXxcmq2upl9tTmNlrbRR9n5e3+fvyvstf/ AA1GT6vpMoV25mde9oyen4+S2u3dU6xwBZH0bWtey/3f8I307P8Agakn2dUeywP6bTY61pY7daIL Jdsqumt29rd7tyQ4aFxH+NSiZa0T/itd31rxhXbYMPKd9noGRcA1ktDrLsVlW0273WPtxbvoN9L0 /wBJ6qrM+uWLTbmuyg6zGrLrcW6kMc11TMfDy3U7m2u3Xfrm/wBXb9l9P/Dq+KLtcSzpmO/De4VC NoaKWOPoiyjbY1zK2n1We7/rdSlW3Pe5nrdOobuJFr97XabPTfDNn+FbXXT9P+bS9Gvp/wCcq5d/ +a0j9demt9IPova9z3svbFZ9HZbXhPL3NtLMn9Yur/oH2uxQyfrNmfsrHzKqqsO3Iz3YJOS4PraG PvpddupfV+dj/vM/9GK9j42S12LXb03FFVAYazWWj0Xls3vorNZ2t9X9HX6aa1vULcY1HpWOWCX+ i+xr2lztx+j6TWbvUd6j3peixURv+8g8VHX/AJpaWH9dMe1uGy/GsbdlCqTWWGoG+23FxXVOusov voyX41l1VtND/wBBsfYjV/XDp9lbbRTeyv16sS19jW1iq6wF1lOTvs/RuxPZVkfmevdVTV6qt5Ay fUrsPTasm6lrttxc1pADvZ6O9tj2eps9X09/6NVcbCysamqmvplT20vNzH33C2wXPc66/INz2Pe6 211n0/3/APgkqgdar/CTcu//ADUXWvrDn9L6hZWG411LMa3JbjNc4ZPp01WWuybHO2111uyWV4td DKr7bf0uT6n6vdSqlv1p6rVjFzXYN9tGUMUmtzg3Ke9mNkVU4O6zbTtqybftORdddXj/AGb1PS2W foNk15jrWZf7Oxxkhx3Oc9pfG3Yx4yBXub9J9f0X/o0A4eQaKqx0jEFVTi1uMdha1jvTst9I7G1t 32+r/g/zEQYaXEeOoQeLWifDQsumdZvyetZXT7bMa2ptfr4z8clx2i27FsrsfusY+yr0qvX/AKN6 V7/Q9O/0/XWyquFSxpfccRmJkX7XZBZsO98fnW1w+70/o77Wq0o5EXoKZI3Wqkkkk1L/AP/Q9VSS SSUpJJMSGgucYA1JPACSl0EZVBc5gdLmu2uaAZB1Ph/JQLb8W5rBbW/2neJBaWkD6e6W+383ch7O nZNm2yixhr4c5r2NkkfRsb+jf7klxFbg8RSHNwb76WMyS20+5lbTG4c7bGOapuwSWta3JvZt7hwJ P9be16dmJVXWWU61PBD63Eua6QG/Tfvf9FqJS8n2umRxPMfyv5TUla8O/wBFsat9QdW6x1sGWufq 7aR3gN/O3IyE62tts7hqIMa8ccfFyb7VTuDZMmTwe0f+SSWkhMkoNuqdw4T56flU0lKSTOcGtLnG AFT+0ZQs2Etlx0YGOcWggnZe6t721u+j+k/m0kiJN+DdSWe3OvrsnIBdU8E1irHuLufb6kCxrPZ9 LcrGPm05DtjG2tcG7iLKrK9P61rGN3JIbCSSSSlJJJJKf//R9VSSSSUws9TYfS2l/wCbumPntVZ9 +W4PY2pu4AAhweWkn2n37Q19f+vpqxbW6wDbY6ogzLNuvkfUa9Cfi2ujblXMgky30zM9vfU9qS4E Ad/zaNd9puNJwq2BhIf+jtgV/Sfsf9lbVY537jH+/wD893aq8ehga2hlUSNtYAALj79ulf09v7qn Tj2ViH5Ft2pMv2A6/m/oa6k9wqZWXPMAdyZmdNp3/vJKsbksLTXWG3Uxv8B+ePzmuQmi7IeXtgVO 1B4/kubH5yq5V9uPQ7I9B+TY5wrppYCd9rvbW2yza70KGu/ncm76H5/qLnerfXXKx6R0/Htbdl6i 7KpZA3EmK8Rjy9m2r+Z+02fzn+DpT445S2DDlzRj8xPhX6X9V38zPOHmMofjH0Q5u/Mvuroph0b/ AEdz/VufWz1N9ez/AM+Iv7a+re7+mY8gHX1BEd/dP8leSXm6y91uS59mTPvttJfZI/lvJctG/Prp IFf6VxAdMw2P5Uf9SpsnLkCPB6pHto1Jc1IfLEH+8+jdOz/2hZtbiubS7dsyqbqsighoZ9N9Vhex 7/U+hs/MV4/aMdw71Dk9vJv8heOU2WYlrcjDudTfEmykurc3+QXD+c/6hdv0n63dTzcGvEusqZ1C 0/q2TY0Cq5zXf0TIa2GUW5Men6jPp/4P0bvSSy8vVEVw7dRTLj5iJ0lYl08f+i9eLTeRs7agHt/w jv8A0V/rsOxoY3aPvPJKoVutZRVlvqOKbGh1lLyCa3O+lU9zC5jv3far1dgsYHtmD2OhVYim1xXo zSQrnXE+nQWh/Jc8EgD+o0s3b/66FkHPZU51O2x/t2sDfhu+nbX7f7SSa0u/o2klljI63GuPq6Np DGe2Ppeoz7d7t0+zZYnN3WwQPSB5BIrZr9MNcN2cNv8Ag3/6/okh00lVxx1Ava+99XpFsmsVlrwT +8/17q/arSSn/9L1VJJCyDcKiaP5wagEbp+W6v8A6tJIFmkqSo3XdQazdWx0zIaGNcYI+hH2hnub Yf30KjI6s58WVkN2uOtLWy6Ds9326z/X8+tJVa06aq5RL3tqH+pOiL6T3GXvcD2DTAH4DcgCt7r3 AWOBggPhsgxt3D27fb/USRIabuJ9Zet01dIpx+nWAjN3NFjNNtTPZft/de5/6H/tz9xcUaKfUbaW gOrBg8aAaE/8W1aX1jFWDmtwy+a+n0U4wfAlx2+s55az/CWuu3OWBm5Xqhtdf82QHE8F09j/AFVc hi0AjoJfpf1T/wCgubnkZTN9PT9m6s7IrtIY1oOw+20OnQ8t4VVFxsa/Lvbj47Q61+jQ5zWDw/nL nV1+5ztrfd9NGf0jqbGl1mPs2sNha59YcA1nr2M9N1nqevXj/rFmNt9dlH6X01YiIwAiDXmWMRNa AtVrtrg6J2kGDpx8FoUU0OrNlgLd7gXVukDe3U+2G7tzv0m1U8jFvx7vs9rB6pDXBrHNsDhY0WVO ZZS6yt7bGP3e1y0LMUXBpveXPY2Gke0B370N+l7v5SZmMeHUkX1j2RLx0e66D9YaL+mNqz7HOyK7 asZzwHPLvXOzDue5jXbfUd+j9Z/+GrWzjGxrnVaA+J11GnH8pcB9V8LKycrK6dbeGV5mOdtjRJbZ TYy7Gs2GGuazc/8ARuXeWWCvLDd43GO4BMjbwqEhEChLirs3+WlKcATR4fTxNlx9Jhgy90mT4/vO j8xqpDMvG7fZt2PAPtrbo7jduvds27mfT2WI79znSdOxJ/2bf+h/6krFtrZYWgXEDbpsY1ujvaGn azb9DZsTC3ogdQC1nZ+eL3ML9rGP1cWUxtBDjuf9tG39G/8Ac9TYz6C2AQRI1B4KyXil1p9mS73N BArrc0gR7g8sd7NPftf6jFdbmjeK/QuaCQ1rtntidu72/RZ/XRYW0kkkkp//0/VUkkklKSQftmKH Ob6rNzCGvbIkE8Bw/N4QndV6Yyd+XSzadrtz2iCPzX7j7fopJII3FNtUnFtF9torL3BrnbWAb3ab 9rd233O2/vKyLmOE1/pAeC3j/P8Aoqvkl9b23GG/DXj+V/KaktkC+b/WnLou6wclzC/E6jTj5lME bwCz0C120ub/ANp9ljN6xRjWucRSPUbyHjQEH+su5+u/1eod0ejO6bUGt6eHF7Gg60WH1Ln93OdT b+n/AKn2hcb019Ye9h0dYBt84n2q/DIPa4ofoiqP9X/0Fzs8TGZvr6vt3RU25fT8qvIq/Q5FR3VP c1r4P0d7G2tsq3Ig6t1INLfX0NRo1rqP6Mitrma1fnNox2ep/O+nj49e/wDQ1rQexr2FjxLXaEf3 LOy8Suhoc2wncYDHRP8AWaW/upuPmITkIyjUzoNOK2KOQ7WQyrzLsrPZflPD7NoqaQ1rGgNbsqrZ XS2uqtv9Ri0IPgsNWMJzjlNLnEhrXFxJOgjv/aT88LgTtwg/gqWoNvUfV7I+xZWV1EsNjMLFssLQ YklzGsbvd7WfRf73/QXb2APyBuaeBIgHtu/lLH+rvQqK+jvs6jVJynMyHVukbW1EW4m7b+c1w9f+ 36a1aB6j3WB2wuMjXQk9mu+i5Z4AEfGy3+TgYYwDpxeqv5f1Uwqqb9BpnyY0fi5jWqiQwXWvEEho MtDHe3d6jv5vF3/+CP8Af/wquuD9d7t7m8MEHXtuj02/572Ko1r5c+wEscQDI0hv9fKsZ/g2fpGJ pb8Ko2WuWMpzDcWVuez3tFgY2XEPcyLKsH1fa7/CMs/9S6TL+oPaXfZqwC2WfpZk6fS/Re1UC3IN z3Ors9EmX7QWyGlvvbYM709/+Fbb6O/0q1ax8TEvYS6m6lzSDtssdvHJD2ll1m36b/zk5gSi7qX5 2LX5xcTp35papC3O3gOx2bN0FwtJO2fp7TU3/MRqqmU1itk7W8biXHXX6Ty5ymkp/9T1VJJJJTQy ftno+o/ayxh9pqNjpP5nqMqZv9Pd9NiqX/ai1l49QNGhZW/Jdu+if8HS99jHMLf0npV2V2f4R9f6 Nat9FVrQXs3uZqyDDp/kulqyzRW+GZNLAaw54YW11u/rH9M//h3+pX+jQ6slCUdNx06fRs4lzzSN 29pGhLxYONPpZgo3ez0/8H/OeqnsrNriHFxnQE/T/stEMob/AOC2LNpubjWhzmtZIlzm/Z2PLBu2 PD7M1+1jZ2b/AE//AEoteh7XtHpOY5xHucw7mtB1hrvz3O/6aSAdPwLTvbmDGfi41wxr2lr6nQCw Fp3+ldIf+gvjZZs/SLi+sfUnqPo/tDp+IWBxd9o6c0tJY5p1twdrj6uLb/OVY7tmRV+5/gKfQnUM t9jeGzufySf3f5X8tDD76HbXCawOTx5BjlLjyyh8tMGXGJfNf8HyzEv3UkWkttoJbc18h7dv+kY7 3tdt/eVDIyH5D9zhDWzsb4A/vfyl6h1np56i8ubXh2gsaw05lBcYBc6yMqp3qM3TX6f+j2f4T8wN X1M+qnpsN+JV620eoGW27N0Dfsa636G5SY54oyOQj1S+UD9D9791p/dDxGiPAnR8xaHPsbVW0vts MMrYC57ifzWVs3Peuz6D9UOo42E7qGVjh+USHY2A8iN0hlVub7mt9Ond9ofjMs/8F/RLbZ0Oqi20 YVzMDCcNorwKW1XvbDf5/Ps32fT9T+b/AODWrdbkWQWj9EdC0dyfo+/+V9H+unZuY4gAKrc/wZcf LC/Vqena2rjsurxm4119mU8udZde50ne53qObVtaz9Wpcf0Xs+grlfr0t2bG3VP1bY3gz+/G5TFL BWLKzuDhJPiPFQ9RlTS8nazUuh20cbvHY3+06v8A421VCbNt6A0Ar6Fja4QGSXO0htXp6Hkba7nH 6P8AOfQ3qsRj11bGNsLnGB6bMffBMbvTj/iqrPYk9/qTZYWlgaXDeQWxq51h3W3V+lua/wDm7fUp /Q1qnddVkO9zh6Y9sPdW8uaQ1u/S+zf7WfmfztaQXTNDh77ungdLwmsFhrZY48b6qWuYR7Ht/Vq2 N3fS3q5RjY2OC3HqZSHGXCtoaCeJO1UsTJvopdWcQllf8yMVjW1ubIG6vdb/ACvV/M/R/wCkWhW/ exr9pbuAO1wgifzXD95FiZJJJJKf/9X1VJJJJSlF1dbnNc5oc5urSQCQePb96kkkprWMudYR6FTm D6D3GTrt37men7fz/wA5RY3ODvSFVNNE6WVvJcByf0PotZuc7/hf+EVtAsx59zCS4un3PdAB0dt2 n936KS7Q10/l1TNaGgNaIA4CTnNA9xAHmsqzEzMcsNTjY7aQGOsyS2fzpcLLW7ff7PUYiU5bm2bL 631uBLS9lLy2DtLHuvsafzf5xJFd22Kqnlz4ho0BGg0/OQm47DWXmZYOJ8WtKYX4pZvuvrADQ50P loBnX1nR7fb/AMEi1vquZurIOO3UOaQWv/Oluz/B/wDf/wDwRWkxANEdvwXppqlwiS1xiddFLa01 PqcJaJbHlG5v5UOvJoYXNse1jw4AguEy5ofxPt/P+khfbqH5Tsap9drnggsbYwOaWhzX7mb/AFfz f3EFVR7dezL1PQZvLwG7osJ+iHHXc/8Ac9Xd/n2Knbe17zZpUxsOe4OiA4O3W05FNrf0H6P1PSsq 96JZVnteCKnPdtAFlTg0TBb76bLdr9n7/wD6TU8fp3qMNmZu9RxMMa97I9vo+5tN76XPcz/CM2JU v4xG61P7zTFr8m4UY1gcSZtNb2nX2brT6GdRaz9+xrK/8Kr37Ix3VNba+wv9psc2yyHFp3f4Syx2 3f8Ay/U/4RWqManHDhUHDcZO5zneWnqOdtRUWIm9SwpqbTWK2lzgJ1e4vdqd2r7C56mkkkpSSSSS n//W9VSXKY/7YPUIrdYM3cDcLPV9KP0ftdu/VvT/AKV/M/8AA+l/gVeEQ9zLMk9Qfbuqofumoudu dS4M/QPwWu+lb72en/N3fzCMhw+LF7v9X+X/AHzupLKLb7L3Mr2Eh7oDjfETb9L/AAXf/X9CrDGd VYwMb6AAEAuNjj8y73O/zk21wnfT7NW6mLmghpIBPA7mElRsozchrGZePi3MBBduLndxvcxj6j+Z u2pwC60g6ljkAhlxJ5b6NkjUt942e36L056hjxq26CJj0LZiN30fS3fnKo7p1xcAcPBexs7SWkHX +T6dm36Vm5DycU42P69mJhNFYPYgNLjsLdwr/SeoxzW/RrS4fJXF5t8Z2NtaQy2HboHoWz7edzfS 9n8jd/Of4NVnZVRa4Ofkmsl01/ZbYLXe30v6Pu9qpNvwmVl7KcAEkkQHAbQ17Xe70fc/3f8AbSib sFji70unuLSDS7a5vht/wNnu3fnMcj7cuyhkA6tn1neo4DNyCSA9jRi67T+cf1f9L7j/AINXTn4m j/TuJ1I/V7p4/wCK3NWYLcNrHRVgMZWTYwgOLW2kRTd/NM3fzf6TZ79mz3qx+zi9gdVg4BDhLSZI 117U+5LhI3RxA+Lc/aeNua0i5u87QXUXNEkhoG99Qb+cray3dK/SDZi4gqGjWlpkNIBe10ex36T6 CJRj5+O9zaacSulxBIr3MJOjdxa1hb/NhCvEJvwLoKp1DqmH05lbsp+02u2Vt7udzAmGq2uc67R0 jJ67h4/U/VcLKnMoZqKS5zo2X7Isd67vTbs3+j+jrqu/nq0YAE63W+iJkgaVe2rvY2RXk0MyKg4M tAc3e1zHQf3q7Qyxn9pqKqDLOoBoBDQIgAVOkaO26eps/dUhb1DcQQyBEQx0nXXmxqRim26kqPrd RjhpM8+k4afD1VeQIpQNv//X9VSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qTwU6+VUklP1Nk f0e3+o78im36I+C+Vkkeiur9VJL5VSQU/VSxOt/8t9D/AOOu/wDPRXzgkn4/m+kv+isyfL9Y/wDS fqpJfKqSYvfqpJfKqSSn/9n/4R0daHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNr ZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRh IHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA2LjAtYzAw NiA3OS4xNjQ2NDgsIDIwMjEvMDEvMTItMTU6NTI6MjkgICAgICAgICI+IDxyZGY6UkRGIHhtbG5z OnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29t L3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NU eXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVt ZW50cy8xLjEvIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5z OnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyIgeG1sbnM6aWxsdXN0cmF0b3I9Imh0 dHA6Ly9ucy5hZG9iZS5jb20vaWxsdXN0cmF0b3IvMS4wLyIgeG1sbnM6eG1wVFBnPSJodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvdC9wZy8iIHhtbG5zOnN0RGltPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvc1R5cGUvRGltZW5zaW9ucyMiIHhtbG5zOnN0Rm50PSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvRm9udCMiIHhtbG5zOnhtcEc9Imh0dHA6Ly9ucy5hZG9iZS5j b20veGFwLzEuMC9nLyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rv c2hvcC8xLjAvIiB4bXBNTTpEb2N1bWVudElEPSJhZG9iZTpkb2NpZDpwaG90b3Nob3A6ZjBiMWI0 MzgtYjlmNS1hZTRkLWFiMTYtNGY5MTk2MDRhNGNjIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlk OjcxY2IwOGJmLWZhZDktMjI0ZS04MGJhLTE1MjNlZDlmYTM1YyIgeG1wTU06T3JpZ2luYWxEb2N1 bWVudElEPSJ4bXAuZGlkOjAxODAxMTc0MDcyMDY4MTE4MjJBQjAxMDZGMUE0MTBGIiB4bXBNTTpS ZW5kaXRpb25DbGFzcz0icHJvb2Y6cGRmIiBkYzpmb3JtYXQ9ImltYWdlL2pwZWciIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgSWxsdXN0cmF0b3IgMjcuMSAoTWFjaW50b3NoKSIgeG1wOkNyZWF0ZURh dGU9IjIwMjMtMDEtMDRUMTI6MzM6MTktMDg6MDAiIHhtcDpNZXRhZGF0YURhdGU9IjIwMjMtMDEt MDRUMTQ6MzE6MDMtMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDIzLTAxLTA0VDE0OjMxOjAzLTA3 OjAwIiBwZGY6UHJvZHVjZXI9IkFkb2JlIFBERiBsaWJyYXJ5IDE3LjAwIiBpbGx1c3RyYXRvcjpD cmVhdG9yU3ViVG9vbD0iQWRvYmUgSWxsdXN0cmF0b3IiIHhtcFRQZzpOUGFnZXM9IjEiIHhtcFRQ ZzpIYXNWaXNpYmxlVHJhbnNwYXJlbmN5PSJGYWxzZSIgeG1wVFBnOkhhc1Zpc2libGVPdmVycHJp bnQ9IkZhbHNlIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJvZmlsZT0i c1JHQiBJRUM2MTk2Ni0yLjEiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0i eG1wLmlpZDowODhjMzFlMy1hNDE1LTc1NDEtOGRhNy04YjgxNWIxODU3MTgiIHN0UmVmOmRvY3Vt ZW50SUQ9InhtcC5kaWQ6MDg4YzMxZTMtYTQxNS03NTQxLThkYTctOGI4MTViMTg1NzE4IiBzdFJl ZjpvcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMTgyMkFCMDEwNkYx QTQxMEYiIHN0UmVmOnJlbmRpdGlvbkNsYXNzPSJwcm9vZjpwZGYiLz4gPHhtcE1NOkhpc3Rvcnk+ IDxyZGY6U2VxPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9 InhtcC5paWQ6MDE4MDExNzQwNzIwNjgxMTgyMkFCMDEwNkYxQTQxMEYiIHN0RXZ0OndoZW49IjIw MTgtMDQtMjdUMTA6NTY6MDktMDc6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIElsbHVz dHJhdG9yIENTNiAoTWFjaW50b3NoKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0 OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NDQ1MTg3ZDgtYTZkYi00 NTc1LWEwODMtMjg3MWIxNTE4OTFhIiBzdEV2dDp3aGVuPSIyMDIzLTAxLTA0VDEyOjMzOjE3LTA4 OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBJbGx1c3RyYXRvciAyNy4xIChNYWNpbnRv c2gpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjb252ZXJ0ZWQi IHN0RXZ0OnBhcmFtZXRlcnM9ImZyb20gYXBwbGljYXRpb24vcGRmIHRvIGFwcGxpY2F0aW9uL3Zu ZC5hZG9iZS5waG90b3Nob3AiLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDpp bnN0YW5jZUlEPSJ4bXAuaWlkOjA4OGMzMWUzLWE0MTUtNzU0MS04ZGE3LThiODE1YjE4NTcxOCIg c3RFdnQ6d2hlbj0iMjAyMy0wMS0wNFQxNDozMTowMy0wNzowMCIgc3RFdnQ6c29mdHdhcmVBZ2Vu dD0iQWRvYmUgUGhvdG9zaG9wIDIyLjIgKFdpbmRvd3MpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJjb252ZXJ0ZWQiIHN0RXZ0OnBhcmFtZXRlcnM9ImZyb20gYXBw bGljYXRpb24vcGRmIHRvIGltYWdlL2pwZWciLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImRlcml2 ZWQiIHN0RXZ0OnBhcmFtZXRlcnM9ImNvbnZlcnRlZCBmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9i ZS5waG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQi IHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NzFjYjA4YmYtZmFkOS0yMjRlLTgwYmEtMTUyM2Vk OWZhMzVjIiBzdEV2dDp3aGVuPSIyMDIzLTAxLTA0VDE0OjMxOjAzLTA3OjAwIiBzdEV2dDpzb2Z0 d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3AgMjIuMiAoV2luZG93cykiIHN0RXZ0OmNoYW5nZWQ9 Ii8iLz4gPC9yZGY6U2VxPiA8L3htcE1NOkhpc3Rvcnk+IDxkYzp0aXRsZT4gPHJkZjpBbHQ+IDxy ZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+R0ZOLUNvdW50cnktT3ZlcnNob290LURheS0yMDIz X3YzPC9yZGY6bGk+IDwvcmRmOkFsdD4gPC9kYzp0aXRsZT4gPHhtcFRQZzpNYXhQYWdlU2l6ZSBz dERpbTp3PSIwLjc4NTk1OCIgc3REaW06aD0iMC42MTE1OTYiIHN0RGltOnVuaXQ9IllhcmRzIi8+ IDx4bXBUUGc6Rm9udHM+IDxyZGY6QmFnPiA8cmRmOmxpIHN0Rm50OmZvbnROYW1lPSJGdXR1cmFU LUxpZ2h0IiBzdEZudDpmb250RmFtaWx5PSJGdXR1cmEgVCIgc3RGbnQ6Zm9udEZhY2U9IkxpZ2h0 IiBzdEZudDpmb250VHlwZT0iVHlwZSAxIiBzdEZudDp2ZXJzaW9uU3RyaW5nPSIwMDEuMDAyIiBz dEZudDpjb21wb3NpdGU9IkZhbHNlIiBzdEZudDpmb250RmlsZU5hbWU9IkZ1dHVyVExpZzsgRnV0 dXJhVCIvPiA8cmRmOmxpIHN0Rm50OmZvbnROYW1lPSJGdXR1cmFULUJvb2siIHN0Rm50OmZvbnRG YW1pbHk9IkZ1dHVyYSBUIiBzdEZudDpmb250RmFjZT0iQm9vayIgc3RGbnQ6Zm9udFR5cGU9IlR5 cGUgMSIgc3RGbnQ6dmVyc2lvblN0cmluZz0iMDAxLjAwMiIgc3RGbnQ6Y29tcG9zaXRlPSJGYWxz ZSIgc3RGbnQ6Zm9udEZpbGVOYW1lPSJGdXR1clRCb287IEZ1dHVyYVQiLz4gPHJkZjpsaSBzdEZu dDpmb250TmFtZT0iRnV0dXJhVC1EZW1pIiBzdEZudDpmb250RmFtaWx5PSJGdXR1cmEgVCIgc3RG bnQ6Zm9udEZhY2U9IkRlbWkiIHN0Rm50OmZvbnRUeXBlPSJUeXBlIDEiIHN0Rm50OnZlcnNpb25T dHJpbmc9IjAwMS4wMDIiIHN0Rm50OmNvbXBvc2l0ZT0iRmFsc2UiIHN0Rm50OmZvbnRGaWxlTmFt ZT0iRnV0dXJURGVtOyBGdXR1cmFUIi8+IDxyZGY6bGkgc3RGbnQ6Zm9udE5hbWU9IkZ1dHVyYVQt Qm9sZCIgc3RGbnQ6Zm9udEZhbWlseT0iRnV0dXJhIFQiIHN0Rm50OmZvbnRGYWNlPSJCb2xkIiBz dEZudDpmb250VHlwZT0iVHlwZSAxIiBzdEZudDp2ZXJzaW9uU3RyaW5nPSIwMDEuMDAyIiBzdEZu dDpjb21wb3NpdGU9IkZhbHNlIiBzdEZudDpmb250RmlsZU5hbWU9IkZ1dHVyVEJvbDsgRnV0dXJh VCIvPiA8cmRmOmxpIHN0Rm50OmZvbnROYW1lPSJGdXR1cmFULUV4dHJhQm9sZCIgc3RGbnQ6Zm9u dEZhbWlseT0iRnV0dXJhIFQiIHN0Rm50OmZvbnRGYWNlPSJFeHRyYSBCb2xkIiBzdEZudDpmb250 VHlwZT0iVHlwZSAxIiBzdEZudDp2ZXJzaW9uU3RyaW5nPSIwMDEuMDAyIiBzdEZudDpjb21wb3Np dGU9IkZhbHNlIiBzdEZudDpmb250RmlsZU5hbWU9IkZ1dHVyVEV4dEJvbDsgRnV0dXJhVCIvPiA8 L3JkZjpCYWc+IDwveG1wVFBnOkZvbnRzPiA8eG1wVFBnOlBsYXRlTmFtZXM+IDxyZGY6U2VxPiA8 cmRmOmxpPkN5YW48L3JkZjpsaT4gPHJkZjpsaT5NYWdlbnRhPC9yZGY6bGk+IDxyZGY6bGk+WWVs bG93PC9yZGY6bGk+IDxyZGY6bGk+QmxhY2s8L3JkZjpsaT4gPHJkZjpsaT5QQU5UT05FIDY0NyBD PC9yZGY6bGk+IDwvcmRmOlNlcT4gPC94bXBUUGc6UGxhdGVOYW1lcz4gPHhtcFRQZzpTd2F0Y2hH cm91cHM+IDxyZGY6U2VxPiA8cmRmOmxpPiA8cmRmOkRlc2NyaXB0aW9uIHhtcEc6Z3JvdXBOYW1l PSJEZWZhdWx0IFN3YXRjaCBHcm91cCIgeG1wRzpncm91cFR5cGU9IjAiPiA8eG1wRzpDb2xvcmFu dHM+IDxyZGY6U2VxPiA8cmRmOmxpIHhtcEc6c3dhdGNoTmFtZT0icjEyMGcxNjJiNDciIHhtcEc6 dHlwZT0iUFJPQ0VTUyIgeG1wRzp0aW50PSIxMDAuMDAwMDAwIiB4bXBHOm1vZGU9IlJHQiIgeG1w RzpyZWQ9IjEyNSIgeG1wRzpncmVlbj0iMTU4IiB4bXBHOmJsdWU9IjMxIi8+IDxyZGY6bGkgeG1w Rzpzd2F0Y2hOYW1lPSJSPTAgRz04NSBCPTE0OSBjb3B5IiB4bXBHOnR5cGU9IlBST0NFU1MiIHht cEc6dGludD0iMTAwLjAwMDAwMCIgeG1wRzptb2RlPSJSR0IiIHhtcEc6cmVkPSIwIiB4bXBHOmdy ZWVuPSI4NCIgeG1wRzpibHVlPSIxNDkiLz4gPHJkZjpsaSB4bXBHOnN3YXRjaE5hbWU9IlBBTlRP TkUgNjQ3IEMiIHhtcEc6dHlwZT0iU1BPVCIgeG1wRzp0aW50PSIxMDAuMDAwMDAwIiB4bXBHOm1v ZGU9IkxBQiIgeG1wRzpMPSIzOC44MjM1MDIiIHhtcEc6QT0iLTYiIHhtcEc6Qj0iLTM0Ii8+IDxy ZGY6bGkgeG1wRzpzd2F0Y2hOYW1lPSJQQU5UT05FIDY0NSBDIiB4bXBHOnR5cGU9IlNQT1QiIHht cEc6dGludD0iMTAwLjAwMDAwMCIgeG1wRzptb2RlPSJMQUIiIHhtcEc6TD0iNjQuMzEzNjk4IiB4 bXBHOkE9Ii02IiB4bXBHOkI9Ii0yMyIvPiA8L3JkZjpTZXE+IDwveG1wRzpDb2xvcmFudHM+IDwv cmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpsaT4gPC9yZGY6U2VxPiA8L3htcFRQZzpTd2F0Y2hHcm91 cHM+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDw/eHBhY2tldCBlbmQ9 InciPz7/2wBDAAkGBwgHBgkIBwgKCgkLDRYPDQwMDRsUFRAWIB0iIiAdHx8kKDQsJCYxJx8fLT0t MTU3Ojo6Iys/RD84QzQ5Ojf/2wBDAQoKCg0MDRoPDxo3JR8lNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3 Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzf/wAARCAGUAfQDAREAAhEBAxEB/8QAGwABAAID AQEAAAAAAAAAAAAAAAMEAQIFBgf/xABJEAACAQMDAQUGAggDBwMDBAMBAgMABBEFEiExBhNBUWEU IjJxgZGhwQcVI0JSsdHwM2LhFiRDU3KS8TSCoiWTwhdFc+KUstL/xAAZAQEAAwEBAAAAAAAAAAAA AAAAAQIDBAX/xAAzEQACAgEDAQYFBAMAAgMAAAAAAQIRAxIhMUEEEyJRYfBxgaGx0TKRweEUI/EF QjNDUv/aAAwDAQACEQMRAD8A+40AoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQC gMOyopZ2CqOpJwBQGI3SRd0bKy+anIpQuzagFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAo BQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUB4j9IHbCfRpItN0lQb6VQzOV3d2CcAAeLGurs+BT8UuDl 7RncPDHk5OmWfb22vrK7vbi4e2eePv4jKrlULDOV8OPLpWspdnaaS3M4R7Qmm3sfQdR1Ww0xA+oX kFuG+HvHAz8h41xRhKX6Udkpxj+pmdO1Ox1OMyafdw3CjqYnDY+flSUJR/UhGcZcMzBqNjcXUlrB eW8lxHnfEkgLLg4OR1HNHCSVtBTi3SYi1KxmuntIry3e5jzviWQF1x1yOtHCSVtbBTi3Se5XOv6O IXm/Wll3cZAZhOpAJ6Dr6Gp7qd1RHeQq7F1rNnHo0+pwXNvLDHGzK4kGxmA4GfU4H1oscnJRaDyR 0uSZxex3bGLXbWeS+NrZzRMSIu+5KBclufAeda5sDxvbcyw51kTvY7n670ruVm/WVoY2fu1cTLgt 5DnryPvWXdzuqNe8hV2SQ6pp8121pDfWz3KkgwrKpcEdeM54qHCSVtbEqcW6T3M3mqafYyrFeXtt BIwyqSyhSR04BooSlukHOMdmy0zBVLMQABkk+FVLHym97T9oe1WsSWPZhngtkyVKEKSo/fdj0z4A fjXoRw48UdWTk8+WbJllpx8EU2rdsOx13C+rSvd20h6SSd4r+YDdVP8AfNSoYcy8OzIc82F+LdH0 e37Q6TLa2s739vCLqNZI1llVWIPoT58VxPFNNquDtWWDSd8l28vrSwRXvbqG3RjtVpZAoJ8uarGL lwizko8siuNV0+2tEu7i9t47eQZSVpAFf5Hx+lFCTdJBzilbZvYalZalGZLC7huFXgmJw2Pn5UlC UeUIzjLhkf650vMw/WNpmAZlHfL7nOOeeOeKnu5+RHeQ8zM2rafBZJezXtulq4BSVpAFb5HxqFCT dJbkucUrb2OB2t1Sw1TsXq76fdw3KpDhu7cNt5HXyrbDCUcsdSMcs4yxS0s5/wCjvVdO03snbrf3 tvbM80u0SyBSfeq/aISlkdIp2acY41bPcrLG0QlV1MZXcHB4I88+VclO6Oq+pzE7TaHJc+zpq1mZ c4CiYcn59K07nJV0U77HdWdR3WNGd2CqoyWJwAKzNDlwdpdEuLkW8Oq2byk4CiUcn0860eLIlbRm ssG6TKHbbtOezVnBJDHDPPLJt7l5Np24OWwOeuB9avgw963ZTPm7tWjq6HqkOr6bBdQywszRqZVi cN3bkAlT6jNZzg4SaZpjmpxtHif0ma3qumatYQaZeyW6ywksq4wW3YB5FdXZccJRbkjl7TknGSUW ULvWO2nZKeGbWHW8tJG2nJVlJ8twAKnyzV1jwZVUdmUc8+J3LdH0iw1S0vdKi1OOVUtZIxJvkO0K PHPljpXDKDjLT1O6M1KOroV4e0eiTRvJHqtmUjIDHvlAGelWeLIuhVZYPqTS61pUKxNLqVoiyrvj LTKA6+Y55FQsc3wiXkguWWLq7trOHvru4igiyBvlcKMnpyaqouTpIs5JK2QSaxpsdkL17+2FqTgT d6NpPkD41ZQk3Vbldcau9jbTtVsNURm0+8guAmN3dODt+flUShKP6kTGcZfpZxe3ur3+laQo0mGR 7qd9iukZfuxjJbGOvgM+da9nhGcvFwZdonKEfDyeBvJO1vZ+wsdbn1aZlumH7GWRm2nGQGVuOQPD pXZFYcjcEuDjbzY0pt8noO1vba5i0TTBpYMV5qMIlZgMmNemF9ScgH0rHD2dOb1cI2zdoagtPLON d3na3sbcWd3qd891BPy8TymReOSpz0bHiK0jHDmTUVRm5ZsLTk7O1237QavcS2Nl2eW5SK5iSVrm OM5O8+6NwHAxyTWeDFBW59DXPlm6UOpyBqfaHsZ2jtrPU9Ra+t5tjOrOXBVjgkbuQQc1pox5oNxV GWvJhmlJ2em7ZN2nvdTt9N0JJra0IHe3i4Ayc+PUADy86wwd1GLlPd+Rvm72UlGHHmcjsjqutaf2 zfs9qV+b+MhgXLF9pC7gQTyPIg1pmhCWLvIqjPDOccvdydn0uuE7hQCgFAKAUAoBQCgFAKAUAoBQ CgFAKAUB8m7eiTSO3tnq88Rkt2MUi48dnDL8/H616PZ6nhcFyed2i4ZlN8HuIu2mgTezrBfpLLcO saRIp37mOOR4dfGuR9nyK7XB1rtGN1TPn0kdpqv6R72HtLOUgWV0QO+xSF+Bc+AI59frXam4YE8Z x0pZ2shtpi22mfpLgt+zcxktHkCPtfeCpUl1z4gdc1ErlgbnyI1HPUOC72TuILX9JWtG5ljiDtOq l2C5PeA459BVcybwRr0L4WlnlfqOyEkdx+kvVpoGWSNhOVdTkEbhzmmZNYIp+gwtPPJr1Of+jns9 p2vS6p+somkEIURgOV2lt3PHjxV+05ZY0tJTs2KORvUbdhbWO97P9p7O53NAsSyhQ2PeXcQf/iPt UZ24zg0MEVKE0zfsJpdrL2Z1vVHRjdwwTRI244CmLnimebWSMem33GCCeOUuv9En6OOyun63p817 qBlZoZwkSI5UKQA2fn0+1R2nNKEqiT2bDGcbZd/SLps2i63adp9NG094omwOA46E+jDg/wCtU7NN Tg8ci/aIuE1kiV+ysEnbHtnca5eRkWlqwZEbkAj4F+nxH1+dWytYcWhcsriTzZXN8I+nX0JuLK4g U4aWJkB8sgiuCLppnfJWmj5N+jnWbXs3qd/Y6z/uzSbUMjj4HQkFT5A5616PacbyRUo7nndmyLHJ xkdH9JnafTNR0yLTdOnS6kMyyPJHyqAZ4z4k58Kp2XDOMtUti/ac0ZR0x3N9X7KzS/o5sC8RF/YR Gbbj3tjEsy/MAg/MVEMyWd+TJnhbwLzRw7W5vO3eq6Pptxu7m1hAnYHO4D4n+ZG0fM1s1HBGUl1M k5Z5Ri+hY7VRz3X6QUsRBbSRwqkdrb3TlIduzIHHmc/MjFVwtLDqJypvNpL+gaXf2HbaCcNo9kz+ 5PZWt3yV2noh58jj0zVMk4yxNbv1ovjhKOW9l6Wc3s3oVrr/AGz1e3vmk7iOSWRkRtu895gAny5z WmTI8eKLRTFjWTLJM7PbjsxM76TbaRJBMlnAVSynnAZlB+IZIyPA1lgzLxOXXqaZ8L8Kj06FCw1e 1vexfaO1h0uCwmjjEkns+dj5IHj0xjpnFXlBxyxbdlIzUsU0lRU0/s9p036Or3WJY2a+jZykm8+6 FYDGOmOtWllks6h0KxxReBz6mZ7u7j/RXaxxO/cvetFIQeiZYhflmijH/Id+RLk/8dfE0vtK7MJ2 Fhvbe7VtUKqcd7lmcn3kKeAHPh4UjPL31NbEShi7m09zbWL/AFOT9G2kpK0hhkuHjZyT76LnYCfL j/4ikIxWeQnKXcRNdd0rsxB2PtLvT7sPqLhMjvdzOT8QZP3cc+HhTHPK8rUlsJwxLEnF7m/aaN7r sBoWp3u9rwMYVkZjzH72Mjz91eaYnWaUVwTlV4YyfJ9E7E6VaaZoFq1ojKbqKOeXcxOXKDJ9K4s8 3KbvodmCCjBV1PE/paIXtBpRJwBFkny9+ursf6JHL2v9aLX6Su1GlX2jDTtPuUupZJVZmj5VApz1 8z0xVezYZxlqkqLdpzQlHTF2cntRbX+ldgdCsZg6LLI8kyHwJyyqfuTjzFaYnGeaUkZ5VKGGMWQ9 ptJ7M2nZmyutKuxJfOUziXcZAR725f3cfTyqcU8ryNSWxGWGJY04vc9Bednxrf6NdMeCMNd2lsJI sDlh+8v1H4gVjHLozu+GbPFrwKuUeW/Weo9ro9E7PrnMR2vJ13Y6Of8ApT8a6NEcOrIc+uWbTjPU 9uuzMs36otdIa2ZbOEqllLKEZgCPeAJGemDXP2fMlqcuvU6M+JvSo9Ohc/Rnq9reG/s4tKt7CeMi ST2fOx/3fHOMY88VXtUGqbdluyzTtVR7eeWOCF5pnWONFLM7HAUDxNcqTbpHU2krZ8i17V4e2evx wSX0NhpFsTtkmYKXz1YA9SfAeA616OODwwurbPOyTWadXSRv29S2tNS0C/sMS6akCJCyHKkRvnAP jwadntxlF8k9opSjJcF79Ket6fqGmafb2FzFcu8nffsm3bV2kDPkST09Kp2THKMm5It2rJGUUkz2 EF7B2Z7I2cmqPs9nto0K/vM+34QPE1zOLy5HpOlSWLGtR8+0ea07RdpG1ztHqNrbRJIDFatINzbf hXHgo8/E12TTx49EFZxwayT1zZ7q97X6THrMmhXouLeVv2ZmdVWMblyDuz0OeuK5I4JuOtHXLPDV oZ4bSjD2b/SDBZ6LdC8tZmSGRjtc4bqNw8Rwcj611zvJhbmqZyQrHmqDtH2CvNPSFAKAUAoBQCgF AKAUAoBQCgFAKAUAoBQFPVNMstWtGtdRt0nhJzhvA+YPUH1FWhOUHcWVnCM1Ujz9h+j3QrG+iu4h dM8Th0V5sqCDkeHNbS7VkkqMY9lxxdl3X+yGj6/KJ72FlnA2maFtrEeR8D9arjzzxqkWyYIZN2bd n+yekaA7S2MDGdhtM0rbmx5Dy+lRkzTybMnHhhj4K+udh9E1q7a7uYpY53+N4X27/UjBGfWrY+0Z IKkVn2eE3bLnZ/sxpfZ9ZP1fCwkkGHlkbc5HlnwHyquTNPJ+otjwwx/pM6D2b03QDcHTkkU3GO83 yFs4zjr8zTJllkrUTjxRx3pI9J7KaVpMN7FZxyql4mybdKWyORx5dTSeac2m+hEMMIJpdTfS+zOm aXpl1p1pHItvdAiUNISTldpwfDiks0pSUnyhHDGMXFdSbQdDsdBtXttOR1jd95DuWOcAePyFVyZJ ZHci2PHHGqieR/SrrLC2g0GzHeXF2ytIq8nbn3V+Zb+VdPZMe7m+hzdqybaF1PU9lNFTQdEgshgy 43zMP3pD1/p8hXPlyd5Ns6MWPu4JHYrM0OBr/ZDR9dl7+8gZLjGDNC21iPXwP1rbHnnjVIxyYIT3 ZW0fsHoWlXK3KRS3EyHKNcPuCnzAAAzVp9pyTVEQ7Njg7PTkAjBGQa5zc5Oh9m9L0KW4l06AxvOR vJYtgAk4Geg56VpkyzyJKRnDFGF6TTtB2X0rtBsbUIW71BhZo22uB5Z8R86nHmnj/SRkwwyfqIuz /ZDSNAna4sopHuGG3vZn3MB4geVTkzzyKmRjwQxu0T6V2b03StSudQs0kW4ud3eFpCwOW3Hjw5qJ 5ZTiovoWhijCTkupW7QdjtJ7QXS3N8s6zqoTfFKRwPDByPGpx5541SK5MEMjtm9n2R0ez0e50uCB hBcjEzFzvfyy1Hnm5KT6BYIKLiupLB2a02DQpdFjST2KXduUyEtycnnrUPLJz19SViioaOhvZdnd Ms9HfSUt+8snLFo5WLZycnk1EssnLV1Jjiio6ehxE/Rt2dW470x3LLnPdNMdvy88fWtf8vJVGX+J juz0t1pVjd6cdOuLWJrTaFEWMAAdMY6Y9KwU5KWpPc3cIuOlrY83B+jbs7FcCVo7iVQc91JNlfrx k/et32vI1RguyY07O5rWgafrVjFZXsTdxEwZEiYptwCB08MGsoZZQdo1nijNUy9aW8dpaw20IIih RY0BOTgDAqjbbtl0qVI5WvdldL1+4in1GOVniQouyQrxnPhWmPNPGqiZ5MMMjuRBpfYnQdMuVuYL PfMhyjTOX2nzAPGamXaMklTZEOz44u0jr6pptpq1k9nfwrLA/VT1B8CD4H1rOE3B3E0lBTVM83F+ jjs7GkimG4kLke88xyuPLFbvteQwXZcaL2tXlr2P7LH2YcQRiK2RmyWY/CPXzPoKpCLzZNy85LDj 2PP/AKKdEaK1m1y7XM90SsRI5CZ5b/3H8BW3a8lvQuhj2THS1vqeh7Q9j9K7QXCXF8s4mRdgeKUj jywcjxNY4888apG2TBDI7Zb0Ds9p3Z+3eLTYSveEF3dtzPjpk/lVcmWWR3ItjxRxqokmt6Pa63aC 1vmm7jdlkjkKBvLOOo9KiGRwdomeNTVM4P8A+nHZz/kXH/8AkNW3+VlMf8XGdeXs1pc2hx6NNAXs 4hiMMx3IeeQ3XPNZrLNT1rk1eKDhofBy9J/R9oemXq3arPcSI26MTuCqnwOABk/Orz7VkkqM4dmx xdnR13svp2vTRy6l7RJ3YwiLMVVfMgDxPnVMeaWNeEvkwxyPxHMX9HPZ1WDCC4yDn/1DVp/lZDP/ ABcZ0O0fZLS+0JSS9R0nQbVmibDY8j4EfOqYs88fBfJghk5IOz3YnSNBuBdW6yzXIGFkmYHZ54AA A+dTk7RPIqfBGPs8MbtcnpawNxQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBV1R7qPTrl7AIbpI2aJX GQzAZAPz6VaFOSvgrK9Lrk8tJ20djO9tAjRPar7IxP8AiXJ2kx/TvE+zV0Ls/n57/A5/8jmvLb4l zTu0Ygur221Z5Mx3MqpMIsRgJGHK5HjjcfzqksVpOJeOWm1Inh7XadPErQR3UrtII1iji3OSVLDo cdFPjxjnFQ8ElySs8XwXv15Zew2V9ucW12yqkhXAUsON3lzx86p3crceqL95GlLoykna3S5IUlhM 8odAyqkRLEs5RVx/ESDgeQJq/cTumU7+LVolTtNYNHIxW4VooZpZY2iw0YixvBHn7wx51Hcy9+pP fR9+hRi7RGM38cvfzzNcyLbJDDuZI1jRskDwBb584qzxXTKrLyYu9avrfszot3G6tc3hhSVzAZD7 yEkhFIJOR0FSscXkkuish5JLHF9XRcXtHBC0dvcJcyTAQrNLHbMqRvJjaGBOVJyOOcZ5qndN7ov3 qWzKtx2lhkNq1nYzstzLJEs7xYwUVjuGeoBX+dWWFq7fBV5VtS5LnZfWhqljDHMJhdpawyymSPaJ N4+JfQkGq5cehuuC2LJqW/JzU17VDpkeusLP9XPKo9m2t3ojL7A2/ON3OduPTrV+7hq0dSneT06+ h0Ju1mlwo7O0oMe7vF2coVfZtbyJbp59elUWGbLvNFGYO1FhcGEQR3MhkR3ISLdsVDhicHwOOmc5 4zR4ZLkLNF8FCbtXGLizvI1uG0+S0nlkRI1dhsZPeOCcAAnx+mausOzXW0UebdPpTOke0uni7MB7 4RiTujc92e637d23d54+nh1qndSqy/exuilc9sLdLYSW9ndvIzQlI5IihkjkcKHXzHp1yR0zVlgd 7sq86rZFnVr7Uxq9tY6Y1qhe2knPtEbMCVZQBkEY+LrzVYRjpcpFpylqUYkFt2ws5LKCeW3uQWhj lm7uPesO87QGb1IOPTmrPBJNqyqzxqzoWuu2d1draQ96bgtKrxlOYu7OCW8gcjB8ciqPHJK2XWSL dI51t2jFvLexXguLiRbydY0gh3FIkC5Jx4Dd8zmrvFaVeSKLLVp+bLMfanT5LiOILcBZCg70xYRS 6b1BPqtV7mVWWWaN0RaXrjaprqpAs8dk1j3yCaLZvO8AOPHBFTPHphvzZEMmqe3FFfS9Yub7tBDb d9K9uIJXJS3CIzCVk97JJAAXAweTVpY1GDfvgrDI5Trp/ZDJ2rlF7FJJa3MdtG92ksaRhmcRFcN9 BnP25qVhVc77fUjvnfG2/wBDqw9p9Mm1JLCOR2lchQwX3dxXcB59PTHhnNZvDJR1GizRctJJcdot Otbw2lzK0UwmSHDjGSylg3/TwRnz4qFik1aJeWKdMrp2r0+QxlY7ru2CFpe5OyIOcJvPhu4PyIJx Vu5kVWaJWuO0sbXdlNGZoLASXAuHliwHEaMTjxOCvhUrDs112IeXdPpub2GrahqOrXEdrFJFCq27 bLqLY0aNvLtjqSQqgc8Z9DSUIxir9RGcpSaXodGy1y0vNPub6ISCC2379wG73Rk8ZyOnQ4NUljak o+ZeOROLl5FVe1NiY2LQ3iS/s+7geAiSUPnaVHiDg/LBzirdzIjvomk3anTjGGNteSYR5JEFuS0Q Rtr7h4EH/TNFhl5kPNHyN7ztBarYz+yM4cM8ETBPd3iIyA/LGKiOJ3v73ol5VTr3tZFY9p4PZ7SO eO6mmZIY5Zo4coJXUHaT0zyPTkVMsLttepEcypX6EGn9rEnijubmOWPvYI2S0SEs7Ozso2tnnO3p gYwTmrSwVsv3KxzWrf7FqXtbp8cQcxXZISR5UEB3QhGCvvHhgkflmqrBJlnmiY7R6rNYT2zQ3Aih a1uJXYxd4MqE2nHBOMnjIpigpJ2uqGSbi1T6Mkn7U6bbiUTNKHh7wSr3fKbCByPDJZceeRULDJ8E vNFckM3aqzlsy1mlzJcMJQI44t7JsAyxwcYGV5BOc1Kwyvch5otbEVzq13Fpeg3BuNrXMe64fuw2 7/d2fOPmAcDHlUqCcpLy/JDm1GL8/wAGuldpk9rvYb2dpdgSVdkWBFD3KOzsPAZJ6knJwM1M8Oya 97kQy7tP3sdfRdbs9ZSVrMvmPbuVxg4YZB4JH5jxrKeOUOTWGRT4OlVC4oBQCgFAKAUAoBQCgFAK AUAoBQCgFAKAUAoDlxdntLijtkjtVC21y1zFyfdkOcn8T+HlWjyzd787GaxRVbcbmzaHp7uzvBuL SvMwLEgs6bGyPIrxio7yRPdxMWuhWNsYSizM0MgkjMkzvtIUqByegUkYqXkkyFjiiRtGsH0f9UvB usu77vuyxPu/PrUd5LVr6k93HTp6EcmgaZIl0htVX2qRZZGQlTvUAKwI5BGBjFSsklW/BHdx325I JOy+lSQJC0MmF37mE7hpA+N4ds5YNgZz5VKzTTsjuYVRJP2d02di7QurmRpC0crIcsoVhkH4SFAx 04qFlkiXiiyW40SxuNPtrF0kWC1KmHu5WVkKjAwwOelQsklJy8yXji4qPkQv2c0150meOYuvdk/t 3w5jPuMwz7xGOpqe9lVEd1G7J00axSK2iWIhLZnaIbzwXDBvnwxqO8lu/Mnu47LyN7LS7SxcPbRl WEEduCWJ9xM7Rz8zzUSm5ckxgo8FVezWlLeC5Fu2RL3wi71u6En8YTO3Prird7Oqsr3ULslm0PTp jeM9uN14yPMykglk+EgjoRjqKhZJKt+CXji725NoNGs4GDoJTIIni3tMxYqx3NznOcjr4eFHkkws cUQR9m9MjjkQQu3eRyxyM0rFnEmN+TnknaOfSp72fv0IWKJsOz2mC89q7hi+7dsMjGPft27tmcbt vGcU72VUO6jdmkHZnSoEKpA5GY9u+Z2KBG3Iq5PCg84FS802QsMETanodhqk0ct5HIzIjINkzplS QSDtIyDgcVWGSUFSLSxxk7ZHddnNLunVpLdlAjSMpFIyKyocoCoIBx4ZqVlmupDxQZtpml+zajqO oT921zeSAZRcbY1GFX1PUk+vpSU7iorhCMKk5Plmlx2c0y4ZnkikDtI8jNHM6E7wA4yD0OBx04os skHiiySPQNNj2hYDhZI5AC5PKJsXx/h4p3sgsUUNM0Kw0ubvrOORXEfdLvmdwqZyFAJOAD4Ckskp KmTHHGLtEllpFlYz99bRFZNjJkuTwzlz1/zMTUSnKSpiMIxdojbQtPYsTCfe77Pvn/i/H4+P4U7y X2+g7uP3+pm30OwtrpbmBJEdce6JW2EhdoYrnBO0AZo8kmqYWOKdozqGh6dqUkkl7bLK8lubdmJO TGSCR9xSOSUdkxLHGXKNJ9A02e7W5kgO9dmVWRlR9nKblBw2PDNSsskqIeKLdmx0LTmhihe33RRG UqrMSP2md+fPO41HeSu79onu41Xvc20zR7PTGke1WXfIio7yzNISFztGWJ6ZNJZJS5EccY8EJ0O3 h0/UYLPcs17GyvLLIzknaVXJJJwBU943JN9CO7STS6kFr2X06KyEMySPKVi3S985ZSg93YxOVAOS APOpeaTdohYYpUyGTslZyXkfxiyW2eJo1mcO7M4ZizA5YHnOetSs8kvUr3Mb9C6/Z3THumuDAwZg coJGCAlNm4LnAO3jNV72VUX7qN2YXs1pa3EU6wyK0ZjZVEzhS0YAViucEgADJp3s6od1G7B7NaX3 KxdwwCxpGhErBkCMWUg5yCCxOetO9ndjuoVRlezmmLC0Igba8MkLkyMSyuwZ8nOSSQDnrTvZ3Y7q NUT3+kWWoKq3cRcLE8Qw5HuuAGHHyFRGco8EyhGXJrPomnTyXcktsrPeIkc7ZOWC/Dz4Y8x5Dyos klVPgPHF3a5IZezmnTRxrKtwzIXPeG4fewfhgWzkg4HHTipWWS4IeKLLEuj2U1tbW0kRMVspSJd5 90FCn190kVCnJNvzJeOLSXkV/wDZrSt4f2b3hxne3K7AhU88qVABHTjPWp72fmR3UPI3g0GygREQ 3OEcMu65kJ4UqB16AHp9aPJJhY4os2OnwWG7uDL7yIh7yVn4QYHUnw6+fjVZScuS0YqPBbqpYUAo BQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAqXOowWtwkM28bgCX2+6uTgZP hk8VDkkawwynHUjZb62dGaCVZiqb9sR3EjwwBS0R3U06kq+JDaatbXcipFvyy5BZcDIAJXPmAQah STLTwTgrZqNashbWtxNJ3MVzF3qNLhQBgHk9AeRVjE2/XWl5cfrK0zHjf+2X3c9M80AGsadj372C M5A2vIAQT08fHFAX6AUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAo BQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoCrc6fa3UokuIhIwXbgk4I9R0P1qHFPk0 hlnBVFmkWlWcMUkUUbJHKmx1EjDI6efX161GlItLPkk0290bW+nWtvKJIo8OECAlieMAeJ64AGeu APKpUUiss05KmyvJoVjJFbwyJIY7eIRxKJWGwDHIIOd3A561JmaHs1pGOLMKemUdlI+oPlkfImgK +oaFptvZTzQaa07RgyLBHMybyByBzgZwM+eBnOBUN0rL44qc1GTpPqduF+8iR8bdyg4znGakrJU2 jehAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgF AKAUAoBQCgFAKAUAoBQCgKA1a1ErJMxgw5RGlwqyENtO0586rqRt/jzq1v8ADp1NpNUs41hYzArN J3aFeRnxPy9fUeYqdSIWCbtVwRXmsQWcV7LLHIVtCgYLjLFsYxk+o64qTIkXWNPKMzXcKbOHDOPd OOR9PTxoCue0Wld8kYvIiGjL94GG1eQAD6nd09DnFAdG2uIbqLvbeRZIySA6nIJBwefmKAloBQCg B5HNAV7A4txGTkxkxn6HA/DFQuDTJ+q/MsVJmKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoB QCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKA5WpajcWl7HHFF3iFNxQRsWf3s EAjgYHPPWqOTTOnDhjODbdC11c3cUrCB7cpFvzKpP1wOoopWJ9n0Nb3v0OfFDFPNpbT2cQa7aSSb KtwwBIxk8Akk+RzRJNWycuWeObjGWy2ObJq5FgIpNFlE0fELEN3e4+GDzjhcKeCR4Yq2lGXfTtu+ fftk9xrdvJDdvJod86S+9KVJGWXG3pyCMckfCR41JkV5r3TjIS+hXLKHI2vu4ZgCec4yc5wP3ucg 0B6MdndJ8LQfPe2fU9ep8T1PjmgJZGbTWtILa0QWPvCWQPjuB+77viCT9Khto1xwjOL336LzOhUm QoBQCgK0PuXc6eDBZB/I/wAh96hcmkt4JlmpMxQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFA KAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQFHuLq3vJ7mO4ku I5dv+7OQBHgY9w+vUg/cVWmnZtqhKCi1TXXz+P8ARYhmiuUO05xwyMMFT5EeFSnZnKLi9yGLNnIs LEmBjiJj+4f4T6eX28slsXfjWrr1/P5LlSZCgFAV5vcu4H8GDIftkf8A+pqOppHeDRYqTMUAoBQC gFAKAUAoBQCgFAKAUBw5u0UcPepJCwlWR1jXkh1VtpOcYHOftVNZ2R7G5U09tvqrLNxq6RwwSwoH SdCVZm24IIHPHA55PhjxqXIzh2dttPobW+qCb2b9i37aGSX3TnGwqMDzzng/1qU7VmWSGiTic2Ht bagkXSouY1kHcSd5tDeDcDBH19OhqShc07tDZ6hcR28KzCZ13bWT4eDnJz4EEfP70B16AUAoBQCg FAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgKeo3clqIDFAZu8l2sqnnbtJJHrx08ahu jXFjU7t1SKVtr8coRWtpzI20e4vALdM55A56nHj5VVTNp9lat2q/BrcaxJFNcopt3EUyR8E7uc5A H7zYx0x1xzijkTHs6aT33T9+i99Te81Se3bVNkSyeyxxsi4P72ck4ycDGeB0Bq5xnOuu1kdqIo8x 3UgdTJLCMRNGSRlSW6+HJxkEUB1tI1qDVfaO6ili7hgG70Adc9Rng8cg4IoDpKwZQykEEZBHjQNU ZoBQEE9ssrB1JjlAwsi9R6HzHoahovGbW3KNIyZhJbXaIWA5x0dT4jy+XhT0ZL8NSibWbtsaKRi0 kR2knqw8D9R+OaIiaV2uGWKkoKAq3zKIg2RujdXxnnAPP4ZqGXxvxV5khuYwcAknOOBUmWpEfti4 yEOKmiNZHPqIhhkk7onYM43deSPypRDyUrJRdjPKHr5+oH51WydZkXcZGSGHGenSljWiRZoz++Pr x5/0NSW1IkHPShIoBQCgFAKAUBS1IzyxNaWM/cXUi+7NsD90P4iDwfQeP0NVd8I2xaU9c1aXTz9C x3CFFEqpIQMElBznr96mjPU72OReaxHavcQzW4IUtHAAuQ2EBOfIcgVVyo6sfZ3NKSfq/wByY6jb 93Z3qwgITJEWIy0YCknG3OeUHT0qdW1mfcPVKLe6/lr8mLK5t7uCzmFnEvtTsxGAdrLk56cniild EZMOiUlfBz4e1WlQoryxd3O+C6woGxk7Rk/YHy5z0NWMDEnbWxe2Z7W3umYxsyF4sLkZxu5yM4/G gJl7ZaWfjEyY4YlVIB8uDz4cjg5wCTkUBb0vtBaand+zQxzpJ3ZkHeoBkDb65/eU/XzBwB16AUAo BQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBxpl1mOaR4dskffMyqSMqu3AHUZHjjIOR1 weKeI64vs7ST2dG0p1aTT7jvYVWbC90tvJtZj1OSTxjpx5HHWniohLCsip7dbI3XVja6msm4sbXb alHAYvtbnjoxOD5Dw6ZqY3e5TL3WlaOd7NdQbXYb0vp0UUtuYEDCQgkMC2doyOcEdTg4xx1qxgba NeaxLfPb6taRwqIVdTGOM5wRncftxj1HNAWvavalu7e4065EQdoTvQFZlxyRg9DnFVu7TRv3ejTK M1fPwNYYbW1hjitY7m1jRQqJHG21QOgxgiiSXBMpTm25NN/I29seIgGWOQf50aM/fGPwpZHdp9P5 J7e9jmcIQVY8DkEE4zjI8cc4qUyksTirLVSZle8VgFnjBLxc4H7y+I/P5gVD8zTG1+l9TSV1SWK5 Q5RwEYjxB+E/c/8Ayp6hK04Pn3Zl7sdI1z5E/wB+o+9Wowc/IrvO79WJHkOMj+8f91CtsjZQwKnk EYJ/D+p+tHwIy0tPyNY2LRqx6kZ+v/k0XBbJHTNo3+XngevIH5VJQq6gf9ynPoo/H/WiKT/Sy0xw Wx4ZP0wP6UouPHHh+WSP5GooUYBPXx6/39QfvUUDZXZPgYjwH9/9v3NKC24J47th8QBHn0P98j7G oLKbLMcySfCefI9akupJklCRQCgIbmfuVAUbpHOET+I/08zUNl4R1fAW0HcqSx3SOcu/8R/p5CiV CctT9CndQJq6iNy4tEdW3I5UyMpyMEfugj6/LrDWo0hJ4d1+r7f39jolQeoBwc9KsYWAoUAAAAdA PCgswyKzKzKCy8qSOlCU2tjAijByEUE+lCDIRFGFVR48CgMCGMdI06AfCOg6UBCljax3sl6kKi5k Xa0niRxx+A+woCzQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAjuJ4raIyzyLHGCAWY4AJO B+JqG6LRjKbqKtiOaOTOxwcEg8+IOD+NTYcWuTSa8t4O876VUEaB3LcAKSQDn6VFomOOcqpcmJLy 3ikmSWQIYYhNIW4Coc8k/wDtP2qShi0vbe7hMsLtsU4O9GQjjPRgD0NASLcQNu2zRnZ8WHHu8A8/ Qg/UUBrJdwRhN8q++yquOcknA6etATKyuoZGDKRkEHINAZoBQCgFAUtQtu8XvYw29cZC9WA5GPUd R9vGqtG2KdbP376klldCeHLEb1A3Y6EeDD0P9R4VKdlckNL9CO8vGjjb2ZO8ceHnzyB6+XqR51dL zMJSpbFGJ1kXaCHjddyY6FT1A+//AMh5VWq2LuTkllXPX+H8zaNiVwxyRwSPH1+oOf8A3CiKZEk7 XD3JUjkk5Rc+vh/ef5CpKJNk6WRI99gPQVBbR5kiWsCYUkknJwT15zRcF5VJ2yUQRDoi/agpAwxF SpiQg9QVFBSMmGM9UX7VNsUiNraA8FQM+RxS2RpRG1mOSjkH1FTZGkhe2lT93cP8v9+X5U2ZGlkW ecHk/wA/7z/8qUVAP1+fGf7z+LeVVaIN7a+kMzoRvjT3dx+It5fy+px4GoJjN3R0Y3WRdyHIqTVN MxNKsMbSOcKvl/L504LRi5OkQ20T7mnnAErDAXrsXy/r6/IVC8y85KtMeDRyb1jGhIt1OJGH75/h Hp5n6edOSV/rVvn3v+C2oCgBQABwAKkyM0AoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAK AUAoBQCgFARXNvHcxd3MMpuVseeDn7cVDVloTcHaOVPoOnxQyyMspRUY7e8PHU8HqPEdcVVwR0x7 VlbSKtxdaTqKsl2s8WYowUUsCnUjIXpjcOehyuPCobi+TSOPPi3hT3fvf4fcsXrWc0b3QVriC9tj CcPtBVA7ZB685PPyNW1bWc8cDcnGWzVfVlJtGsp57WOV7uRrxHleRpRkkBMZAGOOOmM85zk1ZbmM o6W0cewt+zPc29xeie3ZoydsmWXackFjsAGQjHywD1AFCC5baf2bur6O1tjdlpVdQoUooAHJyQDj jHHGR0zzQHoYNMii0iXTbG7lhwXHfRld6MxLE9MA5PTFQ91RpjfdyUnG/R9S2sNwgAW534AH7SME n7YpTGqD6DfdqOY4n/6XI/mPzpuKg+ptHcgyiKWNonYZUNghvPBH8qWQ4bWnZPUlDV3VFLMcCgs4 1wdszSxDapPIBx168+GTg+hwehNQ1pdo1hJZFofv/n2+RurBlyMY+3/jx+XP8NW1HLJOLp+/fvg0 gtJWldI1/Z53qx4Cn95frk/c+QqvIwtxk01s/f33/c6cVpHGxY+8xxkn+lSadEmbXjTJaTNaIrzr GxiVuhbHAPpmpjV78CV065Plv+0faPtJpN1FZMXmjSKcnT0eNkJcq8DHPJwd2QfCvS7nFiknL6/c 83vsuWLUfp9jvaPo2sDtDa6xc2kLq8McebqVhLaBVKsFUEg7uvJPXmsZ5MfduCf7dTfHjnrU2v6P dVxHYKAUB5btRp+sXmq2NzaQW81pp5NykXelZJZgpCrzwBkg5z5104Z44xab3e3yObNCcpJpbLf5 nl4b3tfo1hqMM6XT6lcXMPs7y/tYwWDNJtPQL7uMeGa6XHBkkmuEn/RzqWeCkny2v7PZdjddn7Ra dLfyQpFAZikGM5ZQBkn/AN2R9K5M+JYpaUdWDK8sdTO3JDHIPfUH1rFOjZpMoXltNHGxtxvY8DPh 6nz8/v51ZNPkzlF1sQRIsUQjHQDktznrkn8c/NvMVDRVKlRKkjRtuBI8/wC/v9c+C1SiVd7e/fvg nt2F3MJZSAE5jT1x8X48eQOfGoW506lFaFz1/BvK7XLtBCSsanEsgP8A8R6+Z8Pn0nkskoLU+en5 LKIsaBEUKqjAA6AVJm227ZtQgUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCg FAKAwQGBDAEHgg0HBEba3ZlZoIyyEFSUGQR0xUUi2uS2s37qPYq92m1RhRtGAMY4+lTRGp3dmO5i 3o/drujBCHHwg9cfYUIObcdm9JnlEjWaKQjIFjJRcNndwPMEg+eTQFy206ztpZJYbeNZZHMjybRu LHqc9aAwmmWMbzPHaxK8z75GVcF28yfPio0o1ebI0k3xwbG1gjXOXQDylZR/OlIhTk/+EcaRyFxb 3rlh5SB9v0NPgyW2v1RM7hN/ut6gWQ8qVJAfHip8CPLqPxqPRitPjhx75MrO9swiuiWB/wAOUD4/ Qj+L+fh5VK8mRJJrVH9vfQqzTNK2Sfd8MeH2/vjI5BFacHM3Zp14Iz6cc/l4/LnybijZW2t179+9 mWLOxKEtKfdJyF/r/fgPHOapHTOSyJNrcvgADAGAKsVM0By9Y7QaVoqZ1G8jibGRHnLt8lHNaQxT n+lGc8sIfqZ4TUP0nxQKYdD0tVQE4ef3R89i/wBa649kb3mzkl2tLaCONJ281a7QCe/eEk8iGMIB 9euK0/xoLhGMu0ZH1I5dQvZzma8uJM/xSsfzrnkkuDnlOT5ZF3sn/Mf/ALjXPMybZJHeXUf+FdTp /wBMrD86526K65Lhlde1naPS7gxpqs8qj4ROBICPrXr4o4s+NT0nZj7Tkq7PQaX+lO6QhdUsI5V8 Xt22N9jkH7iqy7Gv/VnRDtj/APZHtez3ajQdURYNOnjhk6i2dRG2SfAdD9M1y5MOSO8jqx5scton oKxNhQEE9usvvD3X8x/f98eVSnRVxs5ksbiTu3XCjrxw3+n/AI6BiTV/AlVjVr9X2/vy8jBdmJVG Ix8Tg9PHr585z65PJUVVlYpRWuXy/Pw+50bF0EYiVQmwYAAx/f8ArzzRFlNzdvktVJIoBQCgFAKA UAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBxHk1qF2YRLNHvkKgYyq7sKCMjPHIwf n05p4jsUezyVXT2+2/v9jN7JrMmnOYoBDcCUACNg2Vx159cUeqiMa7Osm7tUS3X6x7++NpnPsSez 78bO9zJn6/D+FXOQ5rz64qJDZWl08fD95dsgkJDZIJBwBwBjB4YkHjBAT3faaezkEVhFGzRsoIO1 884YZYgeHBz09eAJrS+19rm3WfTgIZXHeMSPdXzxn3fPB3cnHhQHVK6g17L+1tktNi93hCZN3O7P OMdMVXezVPEoLZ6voSezM3+JcTN6AhR+FTRXWlwkZWztwc90rHzb3j9zSkO8l5ie2SUKRlJE+CRO Cv8Ap6dKUIzcfgQO4I9n1BByfckXIVz4Y8Vb0+xNR6MulXih7/KKcsrMO7nYyR9AzAcjPj4fXp/0 mrcbMzvU9WPZrp+PP4GoLK21ssCcBup69D9fHjnybrF1sZtLItUeeq/lfyi+FisreS6uW2rGpdjj O0DJPT6/j51MYtukVSUVqZzez3ae21zUb62tjG0cKxyQSI+e9jYdceBDAgjwrfLgeOKbKYsyySaR 1728t7C3a4u5ViiXqzH8B5msUrNZTjBXJnz3tH21vLyOWDSGa0jwcTcd43//AD/OtcaUZJyVnm5e 2Sk6hsj5lJI8ztJK7O7cszHJJ9Sa9eq2OduzWhAoDvWUpmtkcrtPTA6cVw5lToqycVxzM2ZFc0ij OLqhRrrKPu90AjwX0r1+wqSxVJV/JtjvSU67C4oD13Zvt9qmjlYbtjfWg42SN76j/K35H8K5snZo T3WzOnF2mcNnuj63o+sWWs2onspdwwCyHhkz4EV5s4ODpnoY8kciuJR7W9prbs3ZLJIomupjtgg3 bd58ST4KPE1pgwPK66Fc2ZYlfUu6fewaxZ7grQzBR3kEmO8hJ6BhzjzHmKpODg6LwnGauvkQvEbd tnPoeeef55/E+JPEJKtiJtuVswrFSCpxjGMfh/fPpk81Vop79+/qdO3mEqZ/eHUUNYytEtCwoBQC gFAUItZsJDxcKo27iX90AbivJPqCPpVdSN32fKunurJ3vYFVGVu8V5DGDH73vAHjj5Y+dTaKLHJ2 vmRRalBLFbSKsmLiUxKCuCGAYnP/AGmidqyMkHCWlka6zZlpDI5igRzGLiXCRuwOCFJPJBB+xqSh J+t9M4/+oWnO7H7Zf3fi8fDxoDGm6tZakga1nRmK7+73DeFzgEgHp/WgI49csHCnvwhaNZEV/dLh gSAAepwOlAYftBpS2jXK3sLoAPdVxuOegwT1ODxQEr6tYR3c9rLdRxywBC4dtoG/O0ZPGeOnqPOg Iodd06d7hIbmOQwR94djBty4JJXB5xjB9aAxb6/ps9vHKt1EGkQSLEXXftPQ4BoCRtc0lSoOpWnv dCJVI6E5PkMA80BbguILlWa3mjlVTglGDAHrjj5igJaAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAK AUAoBQFC/lD5i4K/vZ6H+/qPPHWrJbblHJp7FE7kznLp4+JH9ePmf+oVR7FrWR3xL9k/w/oXrKFI IzNK4CYyu48KPn/f2wAig3fikqfv6ng+0up3vaK8EejJqTxwRyRta20ogmhuc+48gJ5THQ9K9HDC OJXOt+vKr09TgyzlldQvbpw7PQhdN7L2Uep39vB+uJbdY5nhUK07gDd6deSa5pTlkelPwmzcMMdU l4vueB1zW7jU5zc38wCjOyMH3UHkB+dXjjfEUebkySyu2eeuNTLKVhQrnjc3X7V0w7NTuTKKJz66 iwoBQHoo3EiK6/CwBFefkVOirILy8W2Krt3sRnGcYquPA8tu6RVRs5VxcyXEm5zjwCg8Cu3Fhjjj SLpJGLZYnk2zsVUjhgehq8m0rRJPeQW0SAwzbnz8OQePPjpWGLJllNqUdvMqm2+CnXSWFAem0a9u bAW9xaytFMqjkfyI8R6Vw5km2Spyg7ifSuzuvWvaezZJFjt9SjR0PuhihIwWTI5Hp965ZReOVdD0 sWaOZU+TxLi/7F6okUERudVuG3PcOSwuVLcIg4LMxAznOzPHWvQWnPG3sl9Pf1OXxYJUt2/qfWAv tNshljMbsoJU8lCR0/KvL4Z6XK3Oc6tG5V+o6/3/AH9BxVmjNqjeGQxyBh6Ajz9P7HyA61mQnT9+ /fB04pElQPGwZT0IOak2TTVo2oSKAUBRvmunmt4bGWNGEivOXTcO68QOeCfA+hqrvobY1BJymvh8 f6NP1Jp2CBbBc+KswPQDqD5AD7+ZpoRP+Tl8yz7Fb9ykPdju0OVAJ4PP9TU0jPvJW3e5qmn26JAi qwWCQyJlyTuIYEknr8R60Soic3N2zyl1LYvdzw3GnSzASyGWOGSQd229hnG4Bd0e4nHxZ8c1JUqG 80cKwm0S4SVUzuWRkjODtVjlhjHOCfh88mgJ4rmHSL21mhsnObSOVo4HkL5bG8sCcAdD094qMnIw QIo9R0TLK2h3LI4bY4l3ghRkgEtgKNowAcY545oCe6i0c3EMFjpUvfXJgk35YDY5AP7wONpIPgTg HmgM3E+mSahfGfs9JMTM3dyhcG4Uja7EkgEBhgDyKkUBrBd6OjzPbaPfFkLJK0pZyVOAxwWJLEOR nrj0oC7pa6Nqc3sP6vkJWEPvkm7wEAKB724k8FcHodp8qA6cnZnR5N++zB3jBHeNgfIZ4PAOR4jN AXrHT7XT1kWzi7sSMGYBieQAB16cAUBaoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgIbqQxw sVOGIwpxnHrUpbkN0jimd4v/AFQwOver8J9Tzx884/zeFTJo53Kuffv2y7ZQiV9xwUH4/wB/3nrV OS8FbJ9W0211fT5rC+QvBMMMASD6EH51eE3CWqPJecFOOmR5rTNG0zsPp017cCKe5GY45ljCSOhP uoecE8cnj8K6MmaWd0uDnjjh2eLk+TweuatcX8819dtufHuqOijwUelaQgrUUefkm8krZ5V3aRyz ksx6k13JJKkVLelwCSUyPgqngfE1z9pyOMaXUrJ7Fi+sRJta3QBi2GxwMedY4e0abU2QpeZQurdr aXYSGBGQR411YsqyxtFk7RDWpJatb6SBQmA6DwPUfI1lPEp79Q1ZXlcyyvI3Vjk1eMdKSBrVgKAU AoDd4nRFZlIVxlT51CaugdeC9iaAPI4UjAYetcs8crpEMLdzaPdJdWsh95y64OCrehqigs6p7NCL d2uUfX+zGs23aKyilmiiF5BhmQgNtJHxKfI1xO4txR6uDNHMt+Uegqp0lS/iJiMiKWdBnC9T/f8A ZFWj5FZLazkiJ5v/AFBATp3Snjn+I+Py4Ho1JIwcb59+/dnTsJAv7LoB08Men94+QqiNIOti9Umo oCO4mEERcgk9Ao6sfACobotGOp0aWsJiQmQgyudzkefkPQdBRImcre3BPUlBQCgFAKAUAoBQCgFA KAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAc69k3y7fBf7z/Y+oqy2RnJlcAsQF5JPH r6/6/jVWzP379/M6ltAltCI41Cgc4AwMnrRKjaMVFUiRmCqWYgADJJ8KFj5L2r1ttZ1EsjH2WLKw r5jxb5n+WK7ccNEfU8nPl7yXocRlDKVYAg9QRU3XBznLv7WKOSIRKVaRsYHIrfFkk076BM6Fvbpb oUjycnJJ6muPJkc3bKN2TCsGVZBdWy3Me08MPhby/wBKvizPFK+gUqOEwKsQeoODXrp2rRsYqQKA UAoBQG0a7nVScZIGcZxUPgHUaEE+wOXI270f+H51xrM3HvfJ0V1bWUUhmhu0Tu8yK2QD0OPyroWS E8baexKaaL09lNKBGJEESsSuQcjPhXPHPCD1VuRqSO1o2oT6TeQ3UDZePhh0DjxB+dedN+K0Vx5X jnqifYbC7hv7OK6t23RyruU/l86J2e9CanFSXUsVJc5d3F3U3Hwtyv5j+/saut0ZSVMjRipDA4I4 B/L/AE4+VUZXj3799DrIwdAw8RQ2TsxLNHCu6V1Qf5jjNLLRi5cIrxA3M/fMrCJOIgwxk+LY/AfX zqFuXfgjp6vn8FupMxQHPOsWSztC0pV1Z1bcpAG0AnJ8uR86rqRv/j5HHUl5fU3m1S2jtnuEYzxo RvMWDt4zk/SjkqsiOCblpez9TSXVYo4LyUxS/wC6EB1IAJzyCOfI+NSnZWeNxSfmbTarZQagthNO qXDQmYBjgbQcdfn/ACNSZkba9pKSd21/AGxn4uPv0z6UBrD2g02WRl9qjVQ6ojsw2yEjPu889cfO gOpQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgNJXEcbMfAURD2OUeevU8/P8Py+ tWZkyxYx7pC56L/OqEwVuzoVJqeT/SBqxs9OWxhbE11kNjqIx1+/T710dnhb1eRy9qyaY6V1Pmtd LPMM1RkCs2VFZsgr3s8tugaOIMPFj+79K0w44ZHUmEkzntqVwVIBQZ8QvNdK7JiTstoRTrqLCgFA KAUAoBQE1vM8c24OAzDG58kD1NZzxxlGnwGrOxbxt/iyyLJIwA3KBgD0rllGMFpiqRWkuCeuaRRi uaRRntP0d6qY7iTTJW9yTMkOfBh1H1HP0NVhLejv/wDH5qbxv5H0AnHWtT1itdKs1uXQggDIIPBF StmVatbHNVwcbAW8AR0+/wDQn5VDafA7pr9br7/sWrVZZQYzN3Sr+7GBn7np9hVdy8JQWyV/H8It xWsMTblTL/xsct9zzU0Wc5PZk1SUFAc69hXUm7kySJBDIru8chQsynIXI8B4/bzqrVm+OXdeKt37 /wCFO/k0e3nIntw0kiCQPGOXy5AwQeuXJ+58Kq9KNsSzyjs9lt9P6J4/1XPCbW3QyCM96IoywJK4 wQePHGDnBqfC9kUffReuW17fuQ2k2m3Za09nZDdgtICSQSCcLuz4gFgB4DNItDNiyabk7S9/0/XY oajd6LJHaXWo6dk38xQy8Zj25XcWyCAPTpkmrnKRxXXZdjP3cEZQqNrruxJxjj+HGAATgZxigLAX sqtzb2w7kTSMvdgF8sSQRk+OTg89eKA9PQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAo BQCgK16xCADPJ6/3/UVKKyKOBg+R+39PxNGZMzql4NJ7P3V4XRHSIlDI2BuPCgn5kVbFDXNRJlLR jcij2Ru9dZXsddht3e3jXN3FcBi7HnayYypwc1rnjj/VDr0K4ZZP0z6Hg+1OoHUtcuZg2Y1bu4/+ lePxOT9a6ccdMEjhzT1zbOTRmBmqMgVmypDd3Atog2AzE4C5xU48feSoJWc1tSuCfd2IPILn+ddK 7LjXO5OlFOuksKAUAoBQCgFAKAsWto1yjMjqCpxg1Vyomjp2EEkEbJIQfeyuDmuXNJN2irNJNSiR toR2IbB4xiqf40pLkrps3W4Mb/tXDQyHMco6D0Nc88OteBeJcr+UUcb4LEt1NYGK9tmIkt5UlGPH B6fKseyKLzaZdUxhlpmmfQe3tpHrfZiC/t95IVWTasjkq+OAikZbO3rwOa6+yy0ZHFnsdpismPUj qdhre/tezsFtqVjHZNFlYoUkLkJ1G7JPOSeM/bpWfaHF5G4uzTs6ksaUlRcdNkjqOcHn+/6is2Wa oltWIlXnI6eg+3+lZiL3OhUmooCtcyO7i3gJEjDLOP8Ahr5/M+H38Kh+RpBJLVLj7kUsayL7BAoW ILiY+Sn935n+XPiKj0LJtf7Jc9DmNeaJbWtstrBBNbI7W37NQe62Bhj7nb/76rcUtjoWPtEpPU2n z8br/vyN9OvtMldbeK07ua4XEiKgOCRlgT5Dp/Kia4Iy4syWpytL2ivbX9tBe2qRWNuD3rW6yRPu CqCBgHHgWx9CBUJq+C88U5Qk3J8X7/Y2vZLJLRVNhaFba9MMYuJMIpwWLEkHGea1PPOb7T2an9ml 9jni9nOTEkWFzwcN54PHz9KAuQap2dRo+5sNshfKr7OAwbJI/EH5enFAd3RtQTU9Oiu0GN4IYDwY HBH3zQF2gFAKAUAoBQCgFAKAUAoBQCgFARtNEkixvIiu/wAKlgC3yFLJUW1aRuzKi7nYKM4yTigS b4I/aYAjSd9HsVtrNuGAc4wfXNA01yY9qtxP3Bni77j9nvG7nkcdfA/ahAW6t2iaVZ4jEp2lw42g 5xjPz4oCVmVVLMQFAySegoAjK6hkYMrDIIOQRQGGZUUs7BVHUk4FCUm9kV2vUKloUaQAZL/Cg/8A cePtmosusT67fcgS5u5RvjQFM8FUyD8iWBPzxUWy7hBbP39GZ9ulQftYMeuGX+Yx+NLHdRfDIpbu OdwQCMDHBB/lmrKSozngkah1ZwocbicDPB/rUNoxeKa6HM7e3caabBpJs1u5NRcxojziFV2Ddu3+ BGBj1rq7NF6nO6r5mPaJLSoVdlPs9JaWHYa51mz9pM13G0kkl1L3kjSD3BluMgEcelXyqUsyg+nk UxOMcDmuvmfP66mcArJlTNUZBXvbj2eEsD754UevnTHDXL0ISs4jMzsWdizHqSa7kklSLGKkCgFA KAUAoBQCgFAX9Lmij7xZGCs2MEng+lUmmyUWr+dEt5FEgEh4AU8isYQbktiDmR2s8nwRMR5kYFay ywjyxaRLCWgjuEkkUYBUxHkk+BHhWWRLJKDivmVe9E4vFeO3d3xsbbIg8Rjg4+lY4+z6MslWz3T/ AIIjGpM+rdlDFrfYuaxlCTqFeHaWwGBGV5HTr+Fcqbhkvhpnp9m/2YHB/A4n6MpdMsb42iX01xf3 Me1ljidbdCgyQC3Jbqc/hXb2tTlG6pL9ynZHCLpO2/2Pe3q4mB8xXAuDskQ7ghDMwGOQWP8AX+tU ZCjJ8Iui8gPwMz/9CFv5Clo6O7l1MG4lZT3VtJnwLkKPrzn8KWToiuWRYaAdzE2+6l95nI6ebH0H QD5DzqOC20vE+F7o1iQSoYYGZbdSe8lz70h8QD/M/Qeglunqlz5eXvois+pGOOYWenStHDKio4Qb JVPLFMdcAH5nFRq8kaLDbWue7T+Xlfvgjt9Wk79I30x1ndsEqMADcQCTjoB1PnxUKXoWl2daW1PZ EkVxKNRkhjgiMUc6jcICpG5W3c+YwvPkfUVKe5VwXdpt7tefwNLmeXZeR2lrC7rfxx42ZyCEJY+o yefQVc5CoddlVjI2lShADvJixvPABzzjoRznwoCU6s8t3aRJpjxNJKBvkjzhD1xxweOfLjrQHoFV VHugDPJwKA2oBQCgFAKAUAoBQCgFAKAUAoBQHH1azj7xp5LgxpN3aELFvkJUkrsPUH6Hz4qkkdWD I60pXV9dt+bI7a1t5bRojfrI91swxzk7f8rEnPunPyPlRJVyWnOSlemtN/X/AKQTLarp1+Hul95j cMy25XakbgEY8cbcfj41MaM8+ppNqkvW/X6m0traw9oJLuW+VGMsb90UPDd26jnOMEBjnGeOTirH Oc230SG4iMMeuf7vBIY3hjQog8Qqjd0OR1zyBtwBigMnTRc2+/8A2knMc0arm43DfvxgEblGDkcD ByeT4UB09E0sWt0kn63e7RYz3cW/jHA3EbiDjGOAB04BySBYghtYpJfZzLfTSStJ+0l3rESegJ4U DHA61RJdNzqlKbS1eFJVxV/kupamRg944lYchAMIvyHifU/hVq8zFzraG33LVSZigOddbWmfcARn Hvf6n8qtSoo5NPZkdvEhmTAwM+Bx09BxVKVkrLN7NljVdKsNXthb6naxXMQbcFkGcHzHlWkMkoO4 uiJwjNVJHnu3gisOzMNnaxrFEZUjWNBgBQCcAfQVt2e5ZHJmHaajjpHzeu1nnGayZU0mkEMTSMDh RnHnVUtTog4VxM88hd/kAOgFdkYqKpEkdWAoBQCgFAKAUAoBQCgLWn2wuJCX+BMZHn6VnklpWwOs tvCG3iFA3mFrjlOVVZVslrnkUZzrzT2kd5Ymyx5KH8jXRh7UopRkvmTGdbMpx2c0sLSIudpwV/e+ 1dM+044TUZPnr0LOSTpn0T9DzSxS6nbyIyqwjkXcMcjIP5VydryQm1pds7+xTTbiey07srpOn6j+ sYoXe9LOxnkkZiSxOTjOOhx06cVlPPOUdLex1RwQjLV1L2pKCqEqzDOMLmsdjdOS4aRTQAfBDj1G 0fyNQ/gVbv8AVk+5eSW47tT3UYGOry/6U3NEoVzfyNfaJBndc2ifUn8xUWX0LyZXG1kkZpcQE5mu OhlP8K+S+HH05yaF900q36Ly9X6lhIWuQvep3Vso92DGNw8N3p/l+/lSrKOShw7fn+PyXOAKsYmq SI8YkR1ZCNwYHII880JaadMjF3bM0aieItJnYN4y2OuPOotFu7nTdcCS6tYVLyTwopk2bi4AL9Mf P0qShPQEC3VuzIomTc5YKN3xFThgPkeKA3mmjgTfM4VchcnzJwB9yKAxFcQyu6RSo7J8SqwJXqOf LoftQEtAKAUAoBQCgFAKAUAoBQCgFAQ3Vslyih2dWRtyOhwVPTI+hI+tQ1ZeE3B7Fa20m1tpxNGH 3g7vebOWwQWPjkg1CikXnnnKOlifSbaaCaFt4WaOSNiG5w7Fmx9TUpUVlklJU/dKiPUNEtb+dppX nVmj2Hu5CoPDAH5gO2D6+gqTMonsdpDMjNFIdjKyDdgLgY6AY8B8scYoDZeyGkKqII5diLtC96en HHn4f3xQFvTdBsdOmE1ur99gguzZJz1oC7Z2lvYwCCzhjhiBLBI1wMk5J+5qEktkXnklklqm7ZPU lBQCgOdLnvXIBHJ6A/0q3QyfJm1B78ZDdDyc1QR5OhUmp4X9KE2yLTIT/wASSQj5hf8AWuvsi3kz j7Y9keAkcRRtI3RRmuurdHAcOWaSZy0jEk+GeBWySRUmtph7PcQyPwyZUE+NUnHxJoFWtAKAUAoD 2vZtOyq2umWtxZNquqX0wjnTLL7OD5dAccdOepzXLk76206S+p14u5pJq2y6nZTR9M1PtBd6gslz pulqpjt93LsyhtrHxxkAfPmqd9OUYpbNlu5hGUnLdIq6po3Z+6sNH162V9M025n7m9iBL93jd8PX nKkceYOKtDJkTlB7tcFZY8bUZrZPktyaZ2Z1vRdbm0fTzZrpi7ob0O2J8KWwQfljnnkGqqeWE4qT u+hZwxThJxVV1Iexlj2d1UWunDR7i+uXjL313I5jFvxxtGeRnjjnxqc0skLlqpdERhjjlUat9TxN 9FDDfXMNtIZIY5nSNz1ZQxAP2rqi20mzlkkm0iKNGkcIgyx6Cp4KnbtLZbaMqDljyzedc+SVgnrm kUZmsZFWKxkVZmsWUZ6r9HLldcmXwa3b8GFMf6jt/wDHv/a/gfSa3PaKOrOkdurOHI3j4N2fHyqU r90Spad/4s5XtURORC7HzKv+a1Vqv+krLtzL5RL1t3bRK/cWik/8w4b6jbVUaRk2uZftRKrMnwGx X5GpJpPmwHh74SXEyzSj4I4gWCfIDPPqfwpsKlVRVL1J+8uZP8OERj+KU8/Yf1qdylQXLv4FWewa SWWSbUrhS9u0bRqwVFBOSwXHxeGc+NQ16mkcqSSUFzfr8Pgc6z0u1ciSLUW9lZEaBA+CEPQHPhk8 CqqK8zonnmtnDfr8SyI7WIqWum7vTcvMrxdTyQxOOce9jH9KlJfsYznJRba/V6kNzp9pdySadPdM sq3BvMIuAA2doJPB8ePHBq5ylJ9Fisu8lk1qYJEgCtv3PvLMeeec8ceJFATxdm7Ys6RapMWbcwCu ucE8k+fPBPjjFAX5tBSe6gmkuZdsSxju14UlCCPkOOnmB5UBC/ZpDI7RX1zGskzzMq4Hvuckg+fQ fLPnQCDs0sFykqX90VSYShGbIAyDgeXTHy49aA71AKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKA UAoBQHFnt8zyZuJxljwJAKu3sYSjvyS2EHd3St31w3B913BFZ9RCNS5Z1ak3Pnv6WyEXRpWOFWdw T5ZA/pXb2P8A9ji7ZxE8NcxGa3eMdSOPnXUnTs4Tj29u85cLgbBk5/lWkpKJUhqwFAKAUAoD2fYn UuzmiQvd3t1cfrSRCqMlsWFuD/DkYLeZ+nnnlzwyzdJbfc6sE8UFbe5Jp2u6Hb3Wr6ZcXF9caRqi KXu5lzKsuPeYjHy5x4eVRLHkajJVaJjkxpyi7plfX9W0eXTNN7OaTcyjTreXvJ72SIks3PIXAJ+I nw8BVscJqTySW76EZJwcVjjx5nQ1PV+ykvZsaPYX2o28MSMwjjgI7+TGQZCRzzz4D7DFIwzLJraR aU8LhoTZHoF/2Rt20/VPaLrSr61X/eLWEOy3LY8+cj0yOtTkjmdxq0/oMcsKqV00eT16+j1PWr2+ hi7qO4mLqh6gevqcZPzroxx0wUWc2SWqbkjOkIC0r+IAA/v6UnwVR0655BmawkZszWMirFYyKszW MijPU/o6UnXZD/Dbt/NaY/1Hb/49f7n8D6VW57RU1Hb3A3HA3Dwpt1LR134eTnYgxkv9yB/M1Xwl 9Wdf+vv9yxFBaOgJuACeoEi0pFlPJW8SZbGBhlZWPyKn8qUiHlkuhItokf8AxpQPIPtH4YqaKvI3 0NDHZAEPNnz3zk/nUbE3k6L6HOnXQGurgFoTdLZnvSj+/wBxu5GfIkVXwWdEX2lRXNXt5WQ2MGiG 6juIphmQxvDCT8DHoPnz08KJRuy+SfaNLi1xdv37ZNPJp8lnq0iyTsH/AGczZyccgFQf3clgD6Hy q0at0c2VTUYqXHv6mmrJot1q5ttSZzMLcMFeTCKCwHHPDHj6VYwKBs+ywlZI5TuIUkrIcEcqfePX pzzn6nkDraJpOkwiO601c7dyq+4+oINAdqgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoB QCgFAc+fIlcDd18M/wBat0M3ya25xOnz6ZFUKx5L7yJGVDuq7jtXccZPkKmmzW0jxP6XbfvOzkEw 6w3S5+RBH88V19jdTaOXtauFnyy1v2hQJIpdR0IPIrvlCzzjo28kMyM0OPe+IYwc+tYTTT3IOPPb S2+O8AwehBzmuiM1LgENWAoBQCgFAKAUAoBQCgOnpBHdyjx3A/hVJlkdCueRDM1hIzZmsZFWKxkV ZmsZFGez/RpCTeX0/gsap9zn8qnEt2ej/wCNj4pM9Vp3aPTNQv7nT4bjbeW8jRvBKNrnB6gHqPlX XLDOMVJrZnowzQlJxT3Rcvj7qD1zz4VSJaddSqM9Rk/36Cqsz+BejiRol3orceIzUUbxbS5DWls3 xW8R+aClIusk11MCztgci3iz57BSkO8n5m6xRR8rGi+oUCpojVJ9TmXuqaa0d6nuXMlqqGSFVzks coucYOSPWqOUdzox4MtxfCd7/cr6fcaO96rWsLGaZgy+5wp25OPLHj6moTjexplhnUPE9l+fdBWt Zrh7AWcaLcyusmyXDHYSd2MdM48erePNSnvRTJjlLHqlLhL6/wA/gjvnsbmJXl062aW4uZI9877V ym5cl8EjIXgf0q5yEB1Hs5FJLC9oA7M4YCLcHKkA89CMjA8OPCgJE1220/S5WtbMgw3XdGIsRnc5 AbdznOOfI5ycDNAWV7V6W2CJJQuSNxjIA5x+NAQL2ttTJgriMO25zn4B0YDHOfKgL95rcVpHaytC 5jm3FyMZiULkkgdceOPnQFE9rbUiIRQyu5ZRKAuQmQM4P72M+HkfTIEh7V2D921v3kkZcq7FCMDn GM9ckDH16YoBN2qshETbrI8mV2qyFQckAnPpn70Ban1yCO2tLqON5YLgnLL1jUKSSR1OMcgc/agK 9v2psJIkZxIjGPvHAUsFGMscjqB50Bkdq9KJz3suzBJcxMAMdc+PHyoDsxP3kSSBWXcoO1hgjPgR 4GgN6AUAoBQCgFAKAUAoBQCgFAKAUAoBQFG8XEuTjBHU/wDj86suDORAG2kNnABz/fhVGU4PN/pP sYJrfT725vhaRwO6hzCZPeIDAqMgBvc4JPjjxrt7HJpuKV2ZdrimlJuh7QO1H6O79Y7h7uWISL3z qFMjxncDgcDIx96OPdZ1tRKfe4HvZ8f6816J5plWZDlWKnzBxUAuu5vbZAZEEsZ94Mcbh51kl3cu NmDWLT5XYZKBP4w2R9KSzxivUiy0NLhxy8mfPiud9qn5IjUyN9KP/DmB9GX+lSu2L/2RGsozwvBJ skGD4HwNdUMkZq4l07I6uBQCgFAKAUBa0+cQz++cI4wT5eVVkrRKOzXNIMzWEijM1jIoxWMirMis ZFGfSP0f2rQaFJcBcvPIzKCcZC8D8QaviWx7HYIacTl5nnewyWF32nlW50+5/Wdq00rTvf8Afor7 tjccYJJ4yOcV6vaHKOPZ7OulFez6ZZXa3V9T31+FeVVIHujjz/rXnpJrc9DvJR4ZWEfOAzg+pz/P P8qq0R3l8xT+X4L4juUGEnRh4B4/zBpua3DyM95dL8UCP6pJ+RH503FQfUx/vcn/AC4V/wC9v6D8 abk+BeoNrCAXuGaXHJMrZA+nT8KUO8lxHb4FGfVVe0uDp1rJPNDKIo1MRCu2M5U9CoB6jyqurbY2 jgqS7x0mr597+hUi1VM3DWOnSLIzFmfZn3sfvDrnPhUavJGrwPbXPY31K9uraNZ4rWN5RAjhjCSQ xOGGfyo21uVxY4Tely2t9SxNIES7tkt4AqWwuAkkZI7xmcncBk4yM8DPWtDjapnKtNYKoRcaQ8u4 FsxW20lSo3YHO7ofHkFeuaEFka2zRyKmjXCd2xVg0YOMcdB18fw86Au6SbXUY3uzYLC+WiO9RyvU +Hjk59c9aA6ItoFJIhjBbqQg54x/KgENtBAu2GGOMZJwqgcmgMiCEEkRR5PX3Rz4UBj2eDay9zHh s7hsHOetADbQEKDDHhSCBsHBHSgENvDACIYkQFt3uqBz0zQGVghViyxICepCjnjH8qA0ns7af/Gh RunOOeDuxnyyM4oCegFAKAUAoBQCgFAKAUAoBQCgFAKAUAoCrer7quOoOP75FWRWRT8T5/j/AF/C qsyNdYtZNR0KSO3t7a4uFAaKO5QMjMp4BB49M+Ga0wyUZJt7EyWvHtuyh2MsNbs4Lj9dOvdz++lu WVjAxZsqNoxt27Prmte0Txya0FOzxyRT1nyDtNph0fXb2xIISOQmP1Q8r+Br0MU9cFI8/LDRNxOZ WhmKA6ejs+JFx7nBz61y9pS2fUiR0q4mUArNlWaSwxzLtlQMB09KRySg7iwm1wc6+sEiiMsJbCn3 lJzxXb2ftUpy0TLxnbpnOruLigFAKAUAoC3FfzRRhAFbHQsORWbxpgy2pXBXA2Kf4gOar3ELIoks b2ZpFhYd5ub4ieQKyz4YaXLgiSVWdUV5kjJm8MbzSpFENzuwVR5knArFlUm3SPqWraZfJ2XGl6Nt E/drEJDMYtnmwI5zkfjXXgcIyTlwj3pY5RxaIFLsBp+q2lrdz63HtuZpFAMiR96wA5LMvxZOcZJO B61t2mcJNKHBHZoTim58nTlleSaR0ZWXPQeHz6fzrkt9DtccaVTTT9/FGYpwjr3i4Geg4z9DjP41 FlV2e94vb35HRW7gY7TIEbwVxtJ+9TaJeOS6E9SUKj3gfItVEpHV84Rfm39M1F+Rqsdfq2+5XBSZ gZC144PCouI1P14+5JqC+8Vt4fuQy3Gs+zQN7HGkwkZpkjlDAxg8KCQOSCPsai5VwXjDBqa1bVtt 1/oitrvVLqGJ1sxDG7KxZeCQTk8Hw/E5zUJyZaePDBtOVssXS6ob1fZ3xB34zkDhNqknpyOGGODk jnipeqzODw6PFzX1t/0a3D6k/tIs8CVbxERnjGO62qTnzGS3I559KucxVi1DtCu8PpCyFRuwZgCc seARwcDHzxnxoDN/d6xHPFJb2k7MttueFcGNnJ6Z65UZPHXgDxoDR9Q17vTINNKqgK7AdwJP1y2M dRj4j5UBtJf6z31v31i0MPehpGi987P4f5fPw6UBlrrXbfUroC0a4tnkCwcgBFx1OOcdfPw88UBo NU144f8AVLKPdG0kYyQD5565Geg9aA9JQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAau6opZ 2CqOpJwKEpN7IqyXAnjZLeN5Qf3gML9z1+mahPyLPHS8TookOchmCgdQo6ffp9lqzT6mTlCPCv4/ hfyW9OYIzR8+9yMnOfvVVsQsjk9y/Ulz5z+lvRDLbQazAuWg/ZT4H7hPun6E4+tdvY8lNwZxdrx2 taPllegeeKA62kNmB1/hfP3H+lcfaV4kysi/XIyoFZsqwKoyAQCCCAQeoNUtp2ipUk063c5AZP8A pPFdEe25Y7Pf4llkkipNpci8wsJB5Hg104//ACEHtNV9i6yrqUCCCQRgjgg13ppq0aCpAoBQCgFA XdJYC6II5ZSAfKubtSvGVlwdivKkZM9X+j/S/a9Sa+lX9la/Dnxc9PsOftVIq3Z2dhxap63wvufS a0PYIbqTu4WPieBUpWyJOkcsorHkcjx8R+Y/CkqZSOScNkyxbQSlGaNkIPG2RchvqP8AWqGuOUXu 1T9A8aIpEsEsA8TCd6f9v9RQ3Tb4d/Hn38yExQbMC6t+6Phzz/7Q2D9vpUUiylK/0u/fWrJkSFgu IZ7nA4LrhR8gcD7Cp2KtyXVIlnF/Lbutv3FvIUIR3zJtOODgYH40d1sUj3aknK2v2KN5HrUbLNDN HJsiWIooxvY43OAeBz0B8M1D1G+N9napqt7/AAjaK21R5klu5EICuCsTleowP/NEpdSHPCk1BeXJ LpFteQ7WumIzFgoZS+1t5OAT1ABxnrSKfUrnnjltHz8q6Fb2fWfYrFreZUnS1Kyidt2XwCM+fIxn 1NXOYrxW/aRWOJrcGXDOxwdp2gHjz4GAOOvnQF/SIdTF3czao0Z3IiII293gsTgfUdfHPhigOtQC gFAKAUAoBQCgFAKAUAoBQCgFAKAiuriO0t5J5iRHGMsQM1DdKy0IOclFcmq3ludoM0asxA2swDZI yBjz9KWie7l5EU+pW8EjJIXyjKrEISF3dCT5U1JFo4ZyVoxJqdtE86ysydw8aSMV4BfG36cjJ8Kk yNYdZ06WJJBdRqsjBUDnaWywUYB5wSQM+tAYTW9NdnAu417tpEcudoQoQGBJ6ckfPPFATjULI97i 8tz3ILSftV9wDxPPFCVFydLkC9icf7uGuM9DEMr/AN3T8ai/Iv3Ul+rb4jbdS/EyQL5L7zfc8D7G m48C9TKWkKsHYGRx+9Idx+men0pRDyS4WxYqShzLqPu5Tjheo9P6fh9avyjKSorGcQtuHxKc48vn 0x9cfWsm6L48M5u1x7/f3udmJxJGrjoRnkVYu1To0u7aK8tZba4QPDKhR1PiD1qU2naKtJqmfAe0 2iTaBq81jNkoPehkI/xEPQ/PwPqK9jFkWSNo8fLjeOVM5VaGZPaXBtpd3VTww8xWeSCnGg1Z3EdX UOhBU8givNkmnTM2bCsmVYFUZBms2VFUZBrI6RoXkYKo6k0jCU5aYq2Qk3sjg3cqz3DyKuAx8a9/ s+N4sag3dHVFUqIa2JFAKAUAoC/pCZmd8cKuM+prk7XKoJFZcHcs7aa8uY7a3TfLI21RXmMzjFza iuT7BoumxaTp0VpFzsGWb+Jj1NEqPew4ligoovVJqcm+uIp7nuN3vR84OQfmP6j71bTtuU71xfhZ EquMBffHUA8H5/64/wDdVHZN45cqn6cft0+R0bW4iAEJLJL4pIME/Lz+hNEzTunFXyi1UlTUIoYs FAY9TjmhNvgga8jJKwhpnHhGMgfM9B96iy6xvl7EMsN/cSQOLlbVI5A7xoocyrz7pJ6fSopstGWO Kaq7+VepQFprUUxEV3GyzO0rMRxGePd5ByMdMY8frWpG/edna3jxt8fX3ZJLpl41pdI0kUs0uzaz OVHGck4HXnOMYzU6XTKxzY1KLqkjWfS3fTNUSN0a4uYWiHvnC4UgZPnzkn19KlKjLLl1pRXC9/8A DTVNN1KXUlvNNmiiItxEWeQ5+LJCgqQpP8XPqOARYxKt3pvaW6gEM2oWhXK52jbuIIOT7vmMYGPA 5HSgLU+may9+lzDqUcSLEsBjCk+7wWfnjdkYHHTxoCoNK7RtMZZdQtyzKEck5BAORwEHiSRyMDg7 utAdvRo7+K2dNUuEmn3kgoQcLgeSr45PTxxzjNAX6AUAoBQCgFAKAUAoBQCgFAKAUBHPEs8LRMWA YYyjFSPqKNFoy0u0cwdndPWVGjRkUHLIGOG4xg+nFU0I6P8AMytU2RyT6XPOZbh2t5lmztkfaWMY 4O3PTB4z6HypcXyWUM0Y1HdV9yScaZIJFkJmTVv2TIDkMApB+QxwfX1q2pGCwz8W3HJy54Oz9n7X rNxavF7FN3bMG6srLtIGfPHHzqTIxcjsvOXe6kjgljMnvmYq2DISSCDzknI9G44NAS2MfZa3naO2 9nzMDbkM29ZAxwVwc5GQBk8dB405JjJxdxdM7NtqOntJNawXEKtasInj+HYcAgfbHSqqS4NZYcqS lJc7lxJEf4HVvkc1Yyaa5NqEFe4u4oCVYlnAzsXk48z5D1OBUN0XjjlIoO9zejeqhIl5DDp9G4J+ mB/mNQm2aOOPHzu/fvf9jnmTAHcAAAZEjjAAPio4xnz4z/mqZJR+JjeXPtHaPv5v7HR0h3i3Ryli GOQWPOfy/D5DxhENY4VCLt+/l8kdarA832r0Oy7V6bJDBPCbu3J7qVWDd2/irY8D4/fwrfFklilb 4ZhlxxyxpPdHxC8tZ7K6ltbuJop4m2ujdQa9WLUlaPKlFxdMhqSCa3uZbc/s24PVT0NZzxRnyGkz sWlytzHuUYI4ZfKvNzYnjdMykqJxXOypms2VFUZBQ1gj2ZATzv4Hnwa7f/Hp9636F8XJyK9g3FAK AUAoDeGMzSrGvBY4z5VWUtMW2DvwQrEixRKfTzJ/rXl5JObtmb3PpXZXRItBsn1LVCkdwy8lyAIl Phk+J4/lWKTk6R6nZsCxR1z5+x3NC1m01yy9ptC6lWKSxSDDxMOqsPA1fJjljdM6ceSORWie/ufZ 4Tt+NuF+f9/P5GsmzfHHUzjb45l23Cgj4g35+nzzx5r0op+Yy9lveP7e/wDpf023kEhZpN8Q5XcP ez8/H59fU0OaEGnv79+2dGWKOZCkqK6+TDNSbqTi7RB7PND/AOmn93+CUFgPkev86ii+uL/Uv2Hs gk5upGm/ynhP+0dfrmleY7yv0qjHtK/4VnGJSvHu8InzP5DJpfkTofM3X3K0un3Esd8Jr929rjCC PACQjBDFPHJB6k9cVXS99zSOaCcaj+n938SsNM1KLc6agzlmLvtG0scAcZ46KBjpzmo0vzL9/iez j79/gke2uHWyludRjDWjd5dAjgsQc854AycZqabrcr3kI66js+Pf3IZ9KaSO5thNbNK957WIHyVd OPdcdcZHqMgdelXOUr22hazCndLrWyJYgqJFEFCEA9AB0yQfWgNRpOspJHbt2hJYqxG7hyPHA8eo 58MetAWbfTtWkttQtL6772OaJoYpHxlfdA3YHXJZvHICqPM0BGdH1zaCutEMJOOOAuSR8zzjwBGP LkC9oWm3diJX1C89qnkCgybcHgt/WgOtQCgFAKAUAoBQCgFAKAUAoBQCgOdd6vBZXTRXQ7uMIGEm c7jnGAB9PvVXJJ7m8OzyyRuPIk1eA2lxNbZmMIyUOVyOeRkc9D064pqVbBdnlqUZbWc65TTi8iGy ABsmujIr4bHio/8AOBTSmie/ywlV8fwQWGu6FPDbm5thb3EOGEckLM0WQWzux/D72fIgmp0oz73J vvzyWNRudPh0+K7t7OK8huLov774G8hgW5B8iKkzOJJL2baMXkUDue5AWyIMcYbA4yR8Y48fKgOn 7f2XaWJ+7USIQyEQOOhDL4cgkgjzPSgOnb6zDLYWd09tN/vkmxUjjL7Tz8WBwPd6mobo0x43O6fC vdlhlSQZGnbvHLqq/wCtR8iybX/v9zX2SQ/BHHCM/uzP+WKUT3i6u/kgtpbWqd5curDdkAjC7vQe J9Tk0pLkPJObqPv38kaSXVxdO0VqrIBwxzgj5n935ct8qW3wSoRgrl7/AD9viQzW62jLuYO5yRjr nxIGfxJz5t4VKSXxM5ynk2Wy98/hEJ3FsYDOMYUdF8s+fmOPkB8VQyqUYxtbLz6v0XkjpRubq0kh MrJKyFe8TgjI+If39+tWi6e5lqUrS2PnFlDd9i9b3zQQXN1Lbvi3sSU79d25ppS3uoBjgeZPQV6U nHPDZ0vX7I4IqWCe+79Puzu63omn9utGt9U09hDetEGjdxgkH9xx98H7ZFYQyS7PNxlwbzxxzxUl yfJdQsbrTbuS0voXhnjPvIw/EeY9a9CMlJWjz5RcXTK9WKlrTpe6ulH7r+6fyrDtENWN+hElaO2K 8hmJms2VKeoXZtlVUALt0z4CunsvZ1mbcuEWhDVyciWV5n3ysWbzNetDHHGtMVSN0kuDSrgUAoBQ CgOlots8s+9EZjnYiqMlmPlXN2iVLSQ99kfWOyfZZdNVdQ1NQbrrHH1EX9W/lXnSdvY9Hs/ZtHjn ycLU9cXthrUmhQXUtjA8bJD3iY72UD3lljbnaQfd6EEZ612wxdxDvGr99GUnl76fdp176nqeynZ+ 37M6YWlSEXkka+1Sw5CuVzjAPTj5ZOTXNnzPI/Q6uz4FBV1Zaeb2lmZhkHjafD0/vPyI5rJNNGk1 KEvt79+pCbZicwZbodv8j16+Rz8m8Kya8jbHnvaXv8fb0MW08sLEQkg55iIzk/Ljn5AN5q3WoTOm UItb+/f7eqOta30VxtU+456KTkN54Pj/ADHiBV07OaeJxMz3kcRKKDJIBkqvh8z0H1o2I429+EVN 73Wd4aZf+VDxH9XON3049Kjk1pQ42+PP7dCyLed49jSLBHjASAcgf9R6fQCppmeuKdpW/UpT6DHL bW1uLq4EcETRZZyzOrY3bmPXIGKq4bUax7U4yctK3d/sYh0u9iuo2OozSRbwXG4jIGTjGSOTtHGO B6mii75JefG4taafv38SSTSWe11KITIpvQeiEKpIIyRk5J4z06DirJUY5MmuMV5Ed/oRuru4uob2 a2mmRE3REggKGx0PPLA/TFSZFaLs9fIVY63csQwLIS+wgHIHx54885PGcjigL2kaOLKONryc313H vCXUy/tFViMqD1AOBkdKA6lAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQEMlrbyszyQROzLtYsgJIznH yqKRZTklSZolhaJC8It4jHIxZ1ZQQxznJ86UizyzbTvdFLU720sryAS23eNIhSSQJnu4/DPHQtgY Pr5VDlRfFgeWLaf9+0QwX2lXc7iK1iLtET3jxqAyqMYJ64weuMYJHpRTTJl2acFbM6K8E6iEWdsk ZUyYj5XcGKZA6YwoxikZWM2FY+H7pM51xqtna2enXT6PBNNeWpc91GODgbV6dGdgvoSCasc5ovaH QAskS6cgdiQwFuuxnKFjk+XUZI5465GQOlpnaDTZp7extIXjEgIjVVUKAN3gDkfC3GOOM4yMgX7W e/uIi0tklqwdl2yShzgHAPu+Y561VNvobTjii9pX8vyJy0QHf3TZb4Y4UALfLqaMRSf6Y/uaR2TS v3kwaMeC7yzn5t4fJfvSiXkUVS3+37fk3E2VMNgqLGnBlx7ifLzP4eZp8CNO9z58upHDF34YQE92 xBe5cZeT/p9PXp5DxovQmTS/V+3RfH38SKSHuCUIAAz8iPE8/jn6knArRJVsck25O5EYkYSfsiQV PvN5eY58fPP15wtUfoWUVBap/Jfy/T7k2o6fZa/Ym0v0ZkJBdVYqTg5xx4EjkfmK0x5JQdxKOMci qR5vRez3aC37U3t+Z4LGzeUKY48SCaFQBGgXA2ADjPXk8V05M2J4lGrf89TDHhyrI5XS/joei7Q9 ndP7QWvdX0X7RR+zmTh4/kfL0PFc+PLLG7R0ZMUcipnyHtL2M1TQWaQobmzHS4iXoP8AMOq/y9a9 LF2iGT0Z5uXs88e/KPOKSCGU8jkGtqvZmB6KGQSxLIvRhmvEyRcJOL6GDVGXcRozt0UEms4xcpKK 6kVex56aV5pC8hyT+HpXu48cccdMTdJJUjSrkigFAKAUB1dB7Palr0/d6fblkBw8zcRp8z+Q5rPJ ljjXiNMeKWR+E+x9leytn2fto8YmuwuHnI8fHaPAfjXl5crySbPSw9njj36lntbpR1jQLq1iDe0B e8tir7SJV5Q5+dMGTRNN8Fs0NcGlyaaHpctjbRXGsXK3t+iYFxJEgeIEDKBgASM55PWpyZFJ1BUi MeNxVzds2ublp3GCVTPuHHQ9MMPn+PHBxnGzpqrTV+a9PNMrhTu9wYcfuj5+HTIz4cc/wt1p8C+p ONTdxfD/AD5P1+50NNliY4biVs48mHjg/wAxwR4+ZlMzlg0br378+pYu7KK6B3jD4wHHX6+Y+dS1 ZaGSUODly2s8blZkMin/AIq5OcdM8HP15HgxqlM6Izi1a9+/29CW1jiBCxpbyEcgST5I9du3r9Kl FZuXLtfL+y+fa/3RAPmWNW3MfB6leRdUzdHfbtGYMQLGpDiTnJJJxjpUeLcunh8PPO/lRTjbXov8 RIpMlQWOCFA4J6g843eOMgYqviNmuzS429+19SUy6tPHYSpCqb33zIDjC+AOTnGCScc5AGOtT4nR TTgi5pv4e/exrdfrFE1HuFmZ5LqMW+CMBNqZPPRchs/WrnKUE1HtQ0zQ/q6HcqBmJUAYJPQ95gkY 4GefErmgOvpMurSM51SCGJSqlBGeQfEHk/6evWgOlQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQG GYKpY9AMmgSs4cevMsTG6sZ45MkqpXAKdVJJ9Dz5YNU1+aOx9lV+GSa/nr/RFLfKDa39lao0s8TD YUYtgA9COMZA9eRUX1ReOL9WOctky1DfTkaaAqBZ7h4mZYyoZFRyCAemdoq8XaOXNFRnSOd/tBeW Nw1tc6RKyoXijNvHhWKgnIyfhIKY9d3lUmRle1Cd4VOkXKSF40O8Abi3XnyGOvjj5CgNZe02ZR7J pd1wO8aQw/Eu7DAeOeOvmOaA6sF3falZ2lxYrFAkjsJxMCWCDIymOCSQCCeMGod9DTH3aT136fH1 9C1tt7JTI5LSPxub3nc+Q8/kKbIm5ZNlx9DVkkuFL3Z7mAAkxBsEj/OfyH1JqOeQmo7R3fvgRQ+1 KGlXbbDHdwYwCPAsP5D7+hKyXLRsufP8fku1YxKMxN4/dwcIh9+X1Hgvr6+Hz6RfkaaVFXLnovyV mi7k7MbcdMcf31/HxY5F6VbHNJtu3yaF2VgsRIfzGPdHT5eGPLjyBzRloRS8cuF9X5fk6NvdCT3X wG/A/wB8feliM75LNSXMEAjB6UB5TXewGi6qWlijNlcNz3luAAT6r0/lXRj7TOG3KOfJ2aE9+DyM vYLXNLdhbmK+tic/s22uvrtP5GrZp48yviRw5exz5juee7QWOo2iBZ7WeKP9/dGR8ufKnYtGp3z0 OaOOUX4lRwMg+I+9emWM0AoDeGKSdgkEbysegjUsfwqG0uSUm+D0Ol9hu0GokEWJtoz/AMS5Oz8O v4VjLtGOPU2h2fJLoe30T9Gmm2e2bWJzeSDnux7kY/M/euWfa5S2jsdUOyRjvLc9boN7p1/p6yaP t9jRjGmyMovHkMDj1rnyRnGVT5OjHKMo3Dg6NZmhHLKkS5Y8+AHU1KVkN0c24la4+M4UcjBxj1z+ f/8AYVLSqiqyOLtFfadxBUFsYZMcOOnAPj4YP/SeNprOzXw0t9uj/wDy/J+hLHGoRJHciNj+zmU8 xt0wc/bn5NzzUGkE03tv1XR+vv4m80Jll2Oqpc/FgEhJseIPUMPPqPUUovGVK1x9v697Mmtb1lLR 3O73TguV5X0cDp8xwfSpT8ys8V7x9/D8cosi8tice0RZ8t4qbRn3c/IMbafhjDJ6Eg02YSnHjYgu LKGWGWGGeW3d0I3QSlWTPGQOn4VDSLxyyTUmr+KKNxb3N2Ik07VBsW1VWYvlnDdHyPE7Rg+rVDTf DNoThC3kh1+3T6/Yyr6pb3cXttxCIJJcEhRgDwAOBjJwOc8Z56U8Se4rDKL0LdIrTRxPpVw0E8Zk vLpFXa7bQd4woz0OBnoMk+WKmPmZ53K1FrhGk9vez6zfXWj6nGZVdIpISxKINo65BGd3gOcE8gmr HOazR9pLYTFL6K491XZVUF14AIQbcckNjyx49KAl0y11+4urK51OaMQx4kaLgMCUK4wF688848gM UB6SgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAayRpIjJIoZGGCrDINCU2naObfXF5azwpY2Zk to0PeBQB14UL8iOeOlVba4R0Y4Y5xbnKm/bIoNXluZ7i39neF0gaQcFnHTHu46ndwOvFQpXsWl2d RipXe/y/c30t9QnkjkuGkWIRZdHjClmJ4HTIIHXwyeKRt8lcyxRTUeb9/v09CpJe6rFp1i6RTSTz QEPiHJEuV27h+6Mb+TxVzmIYta1pLSHvdGmaThHJzuLZIzgLjkAHPTnBIoCe21jVmu7e3m0WURyS bWn38KvmRjg9T5Y8c0B1NPsfZEJluJbqYk/tpsFsE5CjA4AqqjRrky63sqXkhxeyedtGf/uMPyH4 n5czyP8A416v6f2XKkyKZdr1ikTFbcHDSA4L+iny8z9vMRya0se759+6LSIsaBEUKoGAAMACpM22 3bK98V2qgXdM5xGucfX0A8/zxS6JjBS54KbQNB7rc5/ex8Xh0+3HyHTNWS2Msjbfoa+Hh98/+fH8 f4hVWjOvfv3+5KL5rfYjgvubaBnn1+wB+3qKjgnvHHY6EcqSfCefLxqTVNM3oSeJbtTf3Gt6pDZI kVva2JlgS9iaMTMr4d89QoHHT1rs7iKhFvlvocnfyc5JcJdTEH6QIfZbJr7TZw08Mc05hw6QLI5V M5wTnrgDxo+yO3pfH8BdqVLUjrWT9n9dur23j06GZrSTu5ZJLQbSwJBCsRzgg1lJZMaTb59TSLx5 G0lx6Fg9lOz5OTo9l/8AaFV77J/+i3c4/Ilh7OaJCcx6TYg+fcKfyqHlyPqyViguiLM6rYWU0lna xlo0LLEuEDEDpkDj7VVeJpNln4YtpHgJe2+tXsEBsbOGNpp57SSNSe8WQIGjKlgBkgkgEckYruXZ ccW9T8mcL7TkklpXmiG20XXtfntNWkWSK7FrA8U1yxQQTRvh1KddrrlunjUvJixpw6W+PJ/ghY8m RqfWuvmvye70DSI9Bs5reOdmt2neWONukIY52L6A5+9ceXI8jTa3OzHjWNNXsTXt66xP7NjcB8TD gfT6fgfSs+N2ax8T0rnp8TnCYyETtuw/Dq3JUjOR9Ofn7w8RUPwvYvjrNj09V7/p/JllRu4GST0w ev1+3Png9CaWcu90WVscx8uUkHKMo+E/L8MeXHgKijbF4HuRqXDSsIgXHFxb9Q4/iXz/AD6HkVB0 7bK/g/4MHulhUOxksmwY5c8wnwyeoHr1HjT7De9tpeXn7+pu6OCrXEZmwMLPCcPj1A/LPyoQmuIu vR8e/ibw7pFLW12JQOCsqhsehxgj60XoRKl+qNGk7dxFJLPp4kCKWPcKHJwPAHBz6U46Ex8TSjKv jsc+5uNKs9t+bN4J7qzbDLHtkCjBCEeDEtwPMVVuK3o3hDNP/XqtJ+e3x+BXjs9CdlgiupVJZQq4 yG5IAGVwQMsBjpzjoaiol3k7SvE17/f/AKWYGjtUSzeORtt6FeRXHDe6y8Hnbyq48h8syttikk5t zT6flP59SC6aO102UlZ5vYb9WLFl3SHhizHHQbucAnAq6VHLkya5XVHK1NtCvb4XA1SWUvKDLDCA WHGF24HByfi5bA4IxUmYhi7NRMjw3l1NPbHvoothXLZwOAgGSR18QSfHNAegi7U6S0SPJcGMsuSD G+BxzzjBGeM9CeKA6Gl3y6jae0ojIpkkQKwIPuuV5B5HToelAW6AUAoBQCgFAKAUAoBQCgFAKAUA oBQCgFAKAUBx3l1mO6ndLZJYHcCJS4ygHGT068HqePtVPFZ1qPZ3FJun19+hDHc39/YGSOOSKb2g IGiUL7uBkkMeQCSMDrjw5qLbRZwx4503arr/AF5/Q3lXUjYX2O/71rgGH3gGCbhkDBwABkdeRVo3 vZhm0eHT5bkd+dWiv7iW3inlA2+zKrL3IXADb1yCWB3EDIB90ZHNWMStJedqxudNNt/dGBHkHccA j98eOQfLOeccgbXX+0cGr3s1tGZrRincRllKgBPeOMg5z0GRnxIoC3FHqeqR31pqSyWUR29zNbOE c+8c85PgF8viI5xmoatUaYsndzUqT+PB2VCogVQFVRgAcACpKbtlQk33Ckra+LDgy+g/y+vj8ute TT/4+eft/f2LiqFUKoAAGAB4VYy5NJ5lgjLvk+AUdWPgB61DdFoxcnSI7aFlLTT4M79cdFHgo9P5 miRM5J+FcEzqrqVYZBqShTmtWUlo8keQ6j+/6eAqydlHE58A7yV5yMAe5GAOgHUj5kceir51LiZJ W79+/wCifp6Y8vy/v+GqUTRPHcyrwSG+f9/L71G5ZSaNpZbW4Qx3UKsrqUIdQwII5B9CM1Kk1wWV STtHPm7OaHctuFuqHdCT3blQe6+AY6YHlWqzzXXz+pTusb9+Re0XSrfSLaSC1aRlkmeZmkYElnOT 4VWeRzdsvCCgqR0KoXFAaO8YBDsoHiCaCrOfY2mlaXF3en2kMKZ3ERRgZOOpPjx41pKU5u5MyjGE FUUSveOeEUD58n++lUSJ1+RVWR5FzI5ZhwT8vEfz+oonsWypKW3D3RsOPT5eH94/AedLMiskPd3O w+7FNjkH4TkAEfgM+iHzqnobpSlPvYfP4/2i7p7dzO1vMAGzhSB0PXA9COR9R4UW2xvkgmta9++H /Z0qsYEFzAZMSRMEmT4WPQ+YPoahovCVbPgrRlizy2yYfP7e2Y497zB8/wAD+NR8DR1xL5P37RmF AU7zT3CDOGgcEKD4jHVT8vtRehEnvWT9/fJn9hcyhZUaC6A452t9GHUf2abMeKCtO0aSfrKBrhg8 M1utuTENh70y88HHBGMdMGniRK7qSS3Tvfyr7lBb6+LZu9JDuSqr7h4xwxzg8bgSOgxgk81W31Rv 3WOvBP39On1JYlSWGzv7exEJMpcqseTt2MAxA/D5+tT60VbacscpXt/KMR99ImlzTQKZ3umEshgw SNj+8MjKg7V689BUxVq2ZZZaZOMHt8TjTXupH9Z21zoftMcl2/dH2Y444UkbSGOApyeMD4s8VYwJ 4b67K7JuzCvclA0jFMB3HU52Yxy2PHrxjmgMQ3y2zqH7LC3jQKrssROxcjJ4TBAySOf3TnHFAZ1O KSKe5/V2nxLujR7dEsQy3BPxFn2nbjgYOPPnPAElnq95YyRxtos1vYMf3Y9q2yjJY8Dnz8Oh8Tig LF5rGrWmpXMa6W9xahlETqrA8qOMgHPOR4c9cDmgLfZ/Ubq+jliu7cpJbbUkkJHvuVBOAOnBXI8C SPCgOvQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQFHVor2aFEsJFiYOGZ2J6DkDjzOAfTNVlfQ2w yxxbc1ZSWfWVvreOaJO7dzvMa5AX1Ph6VFys209ncJNPckFhfG+SX2kiJZncrvJ908gD59OcgDpg 0p2V73HoarekQPp+pPDKkNw1u51EzBw+f2fgMeIzjK8ceVXOUpw23ayNVi9otAAuS5O/nOeMjPmO fDHjmgAs+0yXskizW5EirktIduVJ8OoySOnGM+lAdG0sr+8tYP1tcOkkUxdo4Su2VOQFfjBHjxUN Wa48mi9lv9PVHZAwKkyNZHWNGeRgqqMknwFCUm3SK9ujTSe0zKVwMRRn9weZ9T+A486heZeTUVpX z9+RaqTMUAoCOSFJOowfMdf7/pUp0Q1ZVe0dfgII8PT++P8AtFTaKuJAV2nDgr5jy/sZ/wC2lFaN OTLk9VGfqf8AwfvVa3L8Y36v7f2bY5x4dPy/MUoyo05Mnl7mR6H+xUVuXr/V8/4MOzG2mIZveR/H 1qYrgnOmpP5fZGqEmzibJOI0PJ6nr+VS+Cez/qj76GZV5YDq0Zxx1I/1aol1L4XUU/Jr6qiUYI3e B5+n/gfjU2YNU6M48zznBP3/AP7fagCROJwCNneDjPmP7H/ZVepqouWP4fZ/hl6K1ROTyfwH94H2 FSQopGt9b9/BhVBdeVHTPmPqOP8AxUNWbY56WUTm5t+894zRAbiB7zr1Df8AUCM/MEeNV5Rt+iVd H7/b+KZfsrgTxe8V7xcBtp49CPQjkVZOzDJDS/QsVJQr3EBZhNCQs6jAJ6MP4T6fy/nDReMq2fBC FFxmaA9zdJ7rhh/8WHiPI/ao5L3p8Mt174K80lpq1tc2WpW0sKd53DCXKCRiM/s24yPUYqNpJpmk VPDJTxu+u3T4ohks7u5mE+nagi252FF3FgdnT6HLZ88L60pvhllkhFackd9/r7VfMxb3N3Z3RTVb 2Pukj3MNoJJYkAZAGRhWJ48PnUJtPdkyhCcbxR3FlFBZTtLd3Me60tQxIJwEYt7xJ68LgeWD51MY 0Z5cyknFLllG4sruTS7OO11SK1Norw3DiQ4DHCkfMAsQT0YL4Zq5zGWt9dt4445tWgijcpFHt94s 2MAZK5HzJJJ5yOlAQWH6+uVZLXtDZzNHkKQgYHgAbvd6jOTz1PrigMh+0kdybe5v1iBColwY1KSS EcKAFz1ByfTovGQPS6Wt0llGt/KstxzuZeeMnHOBk4xzgZ8hQFugFAYVQudoAycnFAZoBQCgFAKA UAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAYyM4zyPCgDMqjLEAeZNAlZoZ4QjO0sYRTtZiwwD0waEtN cmRJG0jRh1LqAWUHkA9MihBmSRI0LyOqKOpY4FAUbeR7+eUyQTQw28xRUlXb3rD98ea+Xn18Kqtz eSWOKpptrp09Pj5nQqxgKAUAoBQCgMEAjBAI9aAp28CS97IRgGQhceQwP5g/eiZacUqXl/02Nnx7 r+HGR6f6CrWZaSFLctcyqrDKhf8A8j/I1Cas0lF92l8TSG1eS1XbtwynqfMj/WkWqGZNzYFnJFY7 XK5SHBwfHbiqvgphi4yj8jcw+/bvu4kbHA6ZBI/kKF4waUl72ZJZW6NAN2cqShHh7px+VFwMkVrb 8y2kaJ8KgVJVJIhvVYwb0GXjIdR548PqMj61DNMb3p9SZGDoHU5VhkHzFSVap0zahBzZl9mvDKnC 43uPQkBvyb6HzqvDOiL1wp+/L8C4to7eTvTuWL+NDhoSf/x9DwPl0NUIzclXX7/2TiW4t/8AGXvo /wDmRj3h81/p9qndFNMZcbP31/JYiljmTfE6uvmDUp2ZuLi6ZS1OEoUvluJIRbZeVYwD3yAH3Dn1 5qrXU2wyu8bV3x6PzOfdajpeqRd3NLPGqMGVkBzu29eAcbSwGfBhiquUZG8MObC7ST9/zX7FafT7 ErbPZGWSKeQRKyMAFG4ZC8AkYBHkBuPzjSuhpHNk8Sns1v8A96fzdIu3Qtb1LBpYX23xSMAPjuwF d/DzwVOPA1elJWcveTwycV0bOfPqmlyz3gvy9tbXVsbZWLj3kR3ViFAyvLHk9AOcVY5ynHD2YvLj d+sbm4upR75CndJuJJBUJ65K44ABI8aAuaDoOiXAgv8AS7ueaOGcurE5Bb6jP1GMjGSRigLydlbB YVh725MKszrGXBCsxyzDjrnn0PNAULPsTAEY31y7SGQkGFVUAYAHUE54yT455zQHQ0/srp9hfxX0 TTG4jBAYlQCCCMYAGBz0HA4oDu0AoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUByLjS J3vZruHUJIpZcKQE42DoOuePePX941Rxd3Z1R7RFQUHG0jS1028ktLu3vpyRJIO7YsXIAIOeemce H2ooummTPNBSjKC4+RtLozPZXkAliD3Ewk3LFtCgMCBjPkMZ+tSlRjly669EV77s5Lc6tPqEOpS2 rSoq/sVwwwB456ZUHp88irGRCOzV46lLnV5JI9gXaVcge8T+85z1AyeQB15oD01AKAUAoBQCgFAR 3EndQSSddqk0ZaK1NIxax9zbxxnqqgH5+NQuBN6pNktSVK9v/jXTf5wPsoqEXlxFe+TNh/6G3z/y 1/lRcDJ+tkzAMpU9CMVJRbFHP/062kbGU7tj6cgH86r0Nv8A7JL4k1rhZrmPyk3D6gfnmpRWe6TL NSZigK1kNiyw+ETkL8jyP54+lQjTJvUvMs1JmVZFD3pRhlWhII9M1HU0TqFrzNrNi0GyTl4yY2z4 48fqMH60RE1UrXUq3F1Fo6qbhiLN3VEIUsY2Y4C4H7pPTy+XSG9PJrGDz/p/V9/7+5tqNkkm26jM yTQHvQIGK96QDhWA+IelGupGLK14HVPbfp6ryKA1LU9rJd6UZAwVNqg4J5DeB4JHGfDriq6pdUbd zh5jOve39+vAmk9qt7O4hsljaScbQYN+Bn4iw+EdSD45HmacpOhFaJSi5XS86+XqawRXMem2pmtk EsF3FHDmIFlQuqsR5Z97nrjBPNTFbbmeea1PQ+effvc0nubyK/f/AHF5vZpcWtskBChNuO8EmMZw WGPp61c5223bKTahcPIWg7LqJpyGeVomO7nluUGeM4zg58Mc0IOnosdvfiYXGhR2ndMirviHvAcj qo6HyyPImgOzb28NtH3dvEkSZJ2ooAyevSgJaAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQ CgFAKAUAoBQCgFAKA1LKoJZgAOpJ6UJps1eaJPjkReccsBzSwot8INNEu/dKg7sZfLD3fn5UIJKA UAoCOWeKL/EkRT5E81FllGUuER+1bv8ABhlk9du0fc4pZOiuWP8Ae3/5UQ+rn8hTceBepj2Xfjv5 pJcYO0nC/YfnSiddfpVE0kscQzK6oPNjipKKLfBD7WH/AMCKWX1C7R9ziosv3dfqdEEc3dLLGB3l w7MxjjO7bnpk9B9aiy7jdPhFy3QxwRoeqqAcfKpRlJ3JszLKkMbSSHCr1qSIxcnSKbI0eksjqQxQ gKeSCTwPxFV6GyaeW0Tp/wCtl/8A40z88tU9TN/oXxf8FipKCgK8Q23s4595Ub+Y/Ko6l3+hFipK Fb/9wHl3P/5VHU0/+v5kEk0tvqqL3H+7XCe9OZANsgOFXb1JI8f8tRdMuoqWJu9109P6/ktXiPLa zRwvskdCqtnGCRweKl8GeNpSTfBwu61G278jVEYQ4ac4yyKBwcEHPujOPFiefCqJS8zrlPC0m4fD 38fobSme7GnwSXUSX7IZ2IJUop8gOMeHJHTqeamm0ikcmKEpUtvuJrV7W1sYp5YYyL6NwnekgDph c8nJOfrUxVIyzTU5WinqEOoWF7JPDrESyMZXFvKSwWN3QAqoUk848+cAYyasYmJB2nF4lvDepKh3 b5wiBE4OVb3c5zgDjjx3c0B0LODX47q0W6vEkjYs1wVRcKoC7QDgHJOc8dM9OKA71AKAUAoBQCgF AKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBybjTLi4mnPtKxxTNlkCk5AAAz68 VRxbOqGeEUtraJLzTYppnmndO5LI8iMg52A4yT4ZwfpipcSuPM4rTHnevmVL7Tobgams90iR3iRS ZA5VExk/X86m0YqEnwvQpQaVIndRW2vyxxy7vY1QswCgepwcLxjgcA4zUrciUXF0zWw0q6u4Wmte 0s0pUtGe7dmRT/DyxPGep56HPShB2Y9JEumW9nqM8tw0TK5kDshYg5GTnJHhyecc1DSfJpjyyxu4 l+KCKL/CjRT4kLilFXKT5ZBLqVrHe+xF2a67rve6VCTszjPAx1pqV0XWGbh3nS6v1Nu9uX/w4Ag8 5W/IZ/nTcjTBcv8AYdxK/wDjXD4/hjGwf1/GlDUlwiINbRSFbWHvph1KckfNj0++ajboWqbXidL3 0JO4mn/9TLtX/lxEgfVup+mKmn1K6ox/Sv3J4oo4UCRIqKOgUYFSUcnJ2zMjrGjPIwVVGST4UCTb pFaGN7iQTzqVVeYoz+7/AJj6/wAqhb7mkmorTH5m1z78sEXm+8/Jef54oyIbJszbjNxct/nC/ZR/ WiEv0pFipMxQFGW5gi1e3geVFmnifYhPLbSCcD61W1dG0YSlicktk19S9VjE5V1JYWmsrc3G9Jzb FBIXO3buzjb0z45xVHSlbOmEck8OmPFkVxdafrJjtorpywzJ3aKVZsAgckcefr8qNqWxaEMuC5Ne hzVsrIw2c5jud0t2sRJmHvEZ97IHvDg/lUKKZpl7Tkxycdv+k95qUAN68sMiWtxKbR594YqyhlJ2 AEgDnk/Pgdb0cTm3FR8irdz6FqbQrNqFwjwxiHZGmRzgZJ2kFc4B5KZxkVJUtt2M0yQBZpLmRF4V XcEDjnw8f744oCzc9mLC6nWed7h5VRIwxlyNij4SOhBPJ4znxoCCbshp8isolnVSoXHuMBjpjKnj zHQ9SMgUB3raFbe3igQsVjQICxycAY5oCSgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoB QCgFAKAUAoBQCgFAKAUBFdRGe2lhV9hdSu7GcZ9Khq0WhLTJMoJosaxzobiZhLGY+SPdU44HHpUa Td9pdp0ttzeHSkhawKytizDgAge9uGPpUpUqMck3OTk+px5Oy+lxSgG4lQRR75UGMyDLck48eQQO u1fIUshQk6aKcXZyI6jBFa6k+0xd825f2iqQVUjjAycE5+IjnPgtEvHJLU+Lowunaakun3H60uMX k6qveAgy7ScqcDxbA97gDgVJQ9XHqFpJO0STKzBA+4H3SOfHp4GgJoLmG4B7mRWIAJAPK5GRkdR9 aAqwWt3L3v6ynSRe9YxxwqUXZn3Q3OScdecelVSfU3lkgq7tVt1339C6iLGoRFCqOgAwBVjFtt2z ahBpPNHbwyTTuscUalndjgKBySTRuiYxcmorllS3Yaj3dyCDa8PDj/ieT/Ly+/liq33NZLurj16+ np+f2L1WMStH797K3hGoQfM8n/8AGo6mj2gl5kWkTrc28kyxzR7ppPdmjKNwxHQ+HFRF2i2eLhJR tPZcF6rGIoChqk8luIHghMshkxtCZJXBJx5dBVZOjbDFStSdIrfrW+3R40qXa7KAdxyoPieOP7zi o1PyNO4x7+PgzNA8uqMZLVJI+8jG9ogfcCsep8mxz60rcRkli2e9Pr6r+ClqHt0Vrqsmm2itdRXC R2+IBnuysZbHHI5b+VWpGDyTapsrDUb1Y4oYuzJZIZQwADRhCPELt685445AznOCVESlKTuTtmHv rmaWWYdl/wBq52vKY8ucYwDuUZ8QTnHkSKkqdXSYrfUbbvrvRobaRJfdV4ucjkMMqD1JHTqDigOz QCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBR utLgu5jLO0hJAAAbAAGeOPPPNVcUzaGeUFUSRLCFLiOfLlok2RgtkKMYyB54FTW5V5ZOLj5lKbs5 YT2trbTCV4rYsUBfBOeSDipMyJeymkhArwvJgg5aQ8kEHw+QHqMjxNAbJpdtodteXGnrJ3rxhVDE vzzgAdeWP41DdI0xRUppPgntdQu57hUfTpIoySrSOTwQD4Y6cYz6ioUm+hpPFCMbUrZBp8uo3EkO 95FjDuXMkGwso4AII4JPPHQdeahNsvljiinXO3W/f5NLi+1SG1SWC2e5k9tljaPbj9mC4XnHA4Xn B/GrnILLVb+8uVguNGkigdmSR3Jwox5FRnyPh5E0CdO0dxVCKFUAKBgADAAoG73ZmgKls2yzedsj fulPBPHh+GKhcGslc9K+BStNSvpO5STTpc+4JZDlRzjJAx65+/iKqpPyNZ4catqfnRG13qHfuqGX b7UI1zanG3xJP8OOh6k+QpbLLHi07+Xn73JLyXUGj1VbZ5Fkj2ezkRBv3QTgEc85q5xlKTWtXJQx aLchIpQshb4pBkg4G3oOuR18OtAWtF1q71C69nudLktGEXeuXkztBJABGAckhvoM80B26AUAoBQC gFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQ CgFAKAUAoBQCgFAVb6+isRC03CSPsLfw8E5/D8ahujTHieS0uhXOs2z2txPbESdwAW3kouD45I6c HpnpUalWxouzzUlGXX5lefVLa+s9Tt2hZu4td00ZfafeVspkcgjGCfM+lE1K0JY54NORPrt8upHc a7p+jNY2EoZFa23DBLd2qr7oPiScEDxJFSlWxjKTlJyfLMntboysFaeQMckAwvyAOvTp4fOpKmqd rtLLHc8qRg43tG3lknHgB0JPjxQHV0+/g1CAzWxYqGKMHUqQR1BBoC1QGAACSAMnqaAzQCgFAKAU AoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgBOBk 9KAUBqXUMFLAFugz1oAHU9GB5xwaA2oDVWV1DIwZSMgg5BoDagFAKAUBFNbwzEGaKOQgEDeoOAeD 96ikWjOUeGYNvbujRtDEyHAZSoIPiMilIKck7TMvDD3bq8cexk2MCBgr5H0qSG2+QbeBgQ0UZBAB BUHIHT7UIKltoum20kskdrGXlkMjM43HcRjjPTjNAWRa2uTiCHIP8A4oDe3ghtohFbxRxRjokahQ PoKAkoBQGMjOMjI5xQGaAwCD0IPyoDNAKAUAoBQCgFAKAUBDLdW8O7vZ4k243bnAxk4GfmalJvgh tImqCRQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUBRm1ewhuZLaS4AnjMY ZArEgvnZ0Hjg/agMaxZx6np8lm0oVZGTcc+AYEj6gEUByrSG9ilvXm1xe7t45PAbYywyrtwBgD93 px68AQWdteXtvb3FvqiPdWZlUmQNwH2kK24A/CM5I5yPCgMfqSSxtIIf1hEkxvS6OIzyzLgDxweO tATNpuqRWCrJrSK/etJPIzHbjAB6+AweOB72eMUBEYLnvTpthrCxvbW0UYjJK7doG7nGDnKHI5HT HvZoCS9sNUKBLvXO77x+6jMaldxPQnHQnB9BQGH0nW1JMOuqB3ZDZUAmTAyxOPT0wOPGgLV9FfXs 6JHqMdrJFCslxbhdwDbvdIYjjo31Cnw5Ahi0nVorK4H61X2iQxlmGVUYzuHjgnI5xk4oB+qdcaZc 9oGeJQVcLGFPUeh5x48YoCFNG1hO9kTWl72XHec9dvAOcdR48c4xxQFbUNN1F7Cae419XgkUoSCd jq+BngcZODgZ44zgmgLVtb6xDqK2z6sr4VpHDDgDgJ4cZbcdvTAAz40BWuLTX47WKe21Y3Q90nZK oVV5O4sRyD1+Rx0GaAsQWd9dWoutP1NEW5TvXILIGcsS2MjOCNqhvAKMdaAlfSNbmLLPrpwMjEa7 NynxOOh69OmKA1mt9VtoLx5tYZIIoVIkcA7j1lOQMgcADjIy3B4oDD6Xrzd2V7QjG3BAjA6rgHOO fe3eXGPEcgQjT9Qa8kkh11GkmjIQK3xwhzgFscHLYBHTJ68mgLH6o1vvC8mue+FYIwXALFcZ29Bj jjnpnqcUBTaw1fS7Zpl1cLEGydp3hd8gJJBHvcMxz1JI44oDv6G84sVN1dJcBsyRy8hihORuBA5A I8B8qA6W5c43DOcYzQGaAUAoBQCgFAeW7d61DpNpbd5fPA0khzDGuWnTaQRn9wZI96ujs+Nzb2Of PkUEtzwVleWEsBmu9Kt5dNiESz3PtUpkbu/gXnG5iTjAGPPArrlGSdJ7/A5Iyi1bWx7bsFo1zbNd 6xc6ibsaiFkjAz8JJILA/vc4wOmK5e0ZE6glVHV2fG1c27s9hXMdIoBQCgFAKAUAoBQCgFAKA8xq +s3c013BpkiW9tZKTd3rru2nHwoPE1vHGkk5cvhHNkySbajslyzh2j9o4pbCWfU5Ylvwe5Mw3qG6 qrjHGR5VaWjelwc6eZNNy5PV6HrDXrzWd9ELfUbfiWLPDD+JfMVhJVwdeLLquMtmiv2t1F9MXTpx LJHELod8E/eQAkiqmfacjx6Xe1le0bWdbBnGpRadERuSCFVkkA8CxPSo3ZSPfZt9WleXLJVv9S0S 6ii1mVLqymYIt2ibGjY9A46YPnVbceSe8yYZJZHafX8nV1hLl7QCz37+8UtsODtzz4j+YqZXWxvm UnHwlcrqXtNo8SHuIlUSq8nvOT8RxznHB6+fWo3Kf7NSa4Xv6EMFrqRju1nklBaNjFtmPx7iRzn3 TjHA4xRJ7lYwy1K39SUwaikqCKQ9yO43B23McMd+Dny6+dKZbTkT2e239nXq50CgFAKAUAoBQFa9 sYL5YluV3LFKsoXwLDOM/egOPD2O0qJmKibB28b+mBjIOMg/yycYoCe37M6fAsgxI5kgNu5JCkpx j4QORtGD8z40BHddlbG8Dm8mupppAQ0zSAMRgAZAAHGOOOpPXJoDU9j9LIUYm2qMY3Dk5yCeOSPD yoDX/Y7TDwz3DDnKll5HTy/Hq37xagJ7/s1Z38k0k81x+0beFDLiNiACQCOchR8WfTFARR9lbP2G W1kd9rz96CuCVAGFX3gRgDP1JIxQEUnYrTHV1Ml0A2ejjOPInGW6eOc+OaAsR9lrGKG7ijknC3Oz OSp27GLDqvPJPxZ8ugxQEkfZrTo7aS3CyGOQoXDNncVJwTkc9fHyHlQFdeyOmbtxe5Yh9x/bEZH8 JxjcOvXJOTzQGp7G6c20ma5yqhQQUBGDwfh6/wDk880BhOxelIxZGuFy6tjcCOMccjjp8x4ECgJb rslp91cTTySXAaV97BSviSSPhz1PU8joCBQFjTOz9rpckr2ks6iVQpXK4wM45Az1Ynrx06DFAUZO xWmSqRJLdMSm0sXH8W7pjA58AMemeaAt3PZjT7m5aebviSFG0SYHu7R168hQCM45PGSTQFaPsZpc cAhVrjGQS28biPe4zjod5z5+PjQGT2O03kK9woPQBlwv/wAfLpnO3quDzQGr9i9MZXUPcKGGMArx 59V5+ucdRg80BvH2UtDAkc00x2ytLiM4GWPQZyRgBVGDkBeMZOQNLLsrHbajJMZx7McbIFjA6A43 HxwSSPp0xigJP9kdKDowWQKgwY/d2t168Z8SMdDxnoKAzH2VsI54J0luFkgdniO5TgkDzXnpnnPl 04oDv0AoBQCgFAKA+R9s71ptevrozTOtswghtMYV9uATnOcbm56EngdCa9HBGoJeZ52aVzb8iTS+ x+r65c97fg2dg8CqAQFK52sQkf7vIPXH1pLPCCqO7JjgnN29kfUbSKC1tora32rFEojRQegA6fYV 57bbtnekkqRMGBJAIJHX0qCRuXnkcdeelAZoBQCgFAKAwSACScAUABBAIOQfGgM0AoBQHyV0tjot wz22oG+WVu+lGe5B3c55xnHnXou9XKr6nlNLQ9nf0Leqx6Z7JD7HZawkrSpsM+7awzyF5646YrBa r3aJyKFeFMmgs+/10HQEvba4t7czYvM7mYHgHJ6EHFZN7bhQvJ/qtNLqeus5NP7T6ehu7ZWeJ8Sw SZzFIOCKzaOyLh2iHiXHQu6fo+n6a7vY2kcDOAGKDqKii8MOPG7iqKnbDu/9mr/vcY7v3f8AqyMf jVJ/pZn2yu4lZvc+3fqW29n7zvtsffd3jvNvG7bnjdUu9JMtfdLTztfn6lNU1wrajfKFlYxyFtu6 JA+Vc443FcqceJFV8Rmln29fpvz8a2InGtsdRC+0BzIRb8gAL3g6H/pp4tyv+/xc+n7/AIN4/wBd KdP7z2hyJGEyDaBjfxlvHC+gz6Gni2JXf+G79f38/gaJ/tF3b792O7ONm3f/AIvPXjds6eFPGQv8 it/e/wB6MS/r32dNnteMSdzju+83ZHd97njGM5xTxB9/XXrXF+lnU02C9TULxrueZ4vd7pWI28jL Y4zweBVknbs3xxmpy1PY6lWNxQHG7TxNLZxbYppCrlgiRl1Y7TgMFIODngjocE9K0xumZ5FaKqaj rCTFprSQRq37WJYGbul3ADawP7QkEk4HGKtphXPv+Cuqd7r3/JHDfa/7puICjnO2NbYsGYAe4WB9 0HJO48fbmXHH0IUsnUuaFdancwsdSTY+GwBAy54XrnpgkgeY58MmuRRT8JbG5NeI5aR63ZWGmCOK a5McfeAyHLRt3LAo4zlhk5B9MHwJv4G376lKmkvfQG77QGcTRRTTxruVA1uYgwG7Dlc5z04PXjgG mnHVEasl2iyb7XgveQQd8qcIHtzGZs7sMcnK4wOPHPhmo04+pbVk6DT21G5vbqa4jmZVtnjhlaAw l/hPwk8HO4fSktKSSEdTbbI7M6vptva20FsrEQowRYCFlY/HufcdhXA69SftL0SbbZC1xSSRDPqW txyQylpFgJEZc2ZBZmaMH3M5yuWx589ccyoQ4/khzn7RZFzr0rRt3TJlginuSMAj/EZd3rnaelVr Gi15Ca1uNZGn3s86P3xljEadznYmFDsqg5b95sefHNQ1C0kSnPS2yvHf9oTE8ns5YAlFU2pUsPfI kxuznCr7vjuxUuOMqpZPaK81reS6IwZJmMmpmRma2fLR5PvGMENjpx9asmlP5e9yKej5+9iSyute gijje2mBAQL3iGQysFQYZs4QHklumc+IOYaxvqSnkXQkn1HW1tyyRS97hiVFix2yADEY55U8+/04 9ahRhf8Afv8AYOU6/r3+5rb6tq9xGzorGFnIeVLNj3OGYAKM/tM4GSOmc+glwgv++6CnNr+vdmPb dduLb9pDLFcFFPdx27ALlQd27OM5J9w5xjnzLTjTGrI0XdP1DUzBe99CJpLJBGAiYM8uNwxzxwVB HmW8qpKMbVdS8ZSp30Kdi2uacsdldKzBZC5uEja437sHZ4YG7fyeg2irPRLdfgotcdn+ST9Ya13a nupO8JJZfY2wJOMRZz8PX9p04600w9v6/wBE6p+19P7Nvb9ek27bXYY896DATuYE+6DnoRj3hmmn H5jVk8iXRb3UI7lbXVO8YMirHI0BXL8kgnoTgE8cDHOD1icYtXEmEpJ1Ip3tu8upXTQW96sasBcZ STN0hdS+09MKBgAckbgPWYuoq3/RVrxOl/ZpBbye12iGC9iHel4pikh7iEOSsfkC3jnouAecCpb2 YS3RLbQSNoeseywXcPexFYreRHDjCkbufiZupx6eOTUN+KNkpeCVENx7fstra2t39nR1kjWOzdA5 yxJOTmPBA4PXOR14stO7f3KvVsl9jNvda/BHJ3kc5JZijtAZCTltqbQeAeBu+WeuaNY2E8iO1o8+ pST3A1GIIhG6PCY2++425z73Cqc/5qymopLSawcm3qOrWZoKAUAoDydp+qbHtjPbsiteTqzi4k/c YsD3a+XxA+ZzXQ9csV9DnWiOVrqenuY3ltpY45DG7oVVx1UkYzWCdM3atHnxpl8JEe1htbXu8FUQ jJIVlLBsf5sDIJyc+lba49dzHRLpsbJZ63HLLIsqgyAFj3i5IAxt+H48Y97p6U1QolRmiX9WXk2m zxXjp3080TM2QeFK58ME4Hlg1GuKlaGhuLTMSwa0jukVwgTfhBuQEjnbj3eABjI5zg4x4k4Cp+ZH Bb62J5IEuWCKRmUkYIYkttyuc8jB6DGKlvHV0QlO6smNlqa93vulSFJVZlVgoChg3l1POarqj5Ft MvMjn0q/Z55LS5jV2uzLsdiyjA90jyPmOhHrUqceq6EOEt6fU3htNbVTIt2gmZVBWYhhgbvIdfhG R1yfECjlj8goz8w1tq0jPFLdq0TZVjuUb+Dwo2+75Hr6YpcFukKm9rOlpMNxb2EUN2VaVFCkp8Jx 5eQ/vms5tN2jSCaVMuVUsKAUB5rVNHvLa5urrSo0uILwEXdjI20OcYLKfA1vHImkpdOGc08ck247 p8o4Gn2/aD2m1WXTZpksgRaLcMFVCejOf3sDpirScN6fJzxjmteHjg9foelPY9/c3swuL+5IaaXH HHRV8gKwk74OvFjcbcnbZBqej3C3v6z0WVIb3GJY3/w5x5N6+tVKZMMtWvG6f3IhruqRjZP2euzK OvdOrIT86iyvf5Fs8bs1Wx1HW7qKbWYktbKFg6WatuZ2HQuen0qtOXJHd5M0k8iqK6fk62qNOlun s7SqTIodok3MFzyQMH+VWZ0ZXJLYpe06oPZT7PIyrlpztALKWIXj+Lb7xA8eKrbMteXbb4+/qXdO F2Wm9rfIRtkfuY3AfvH1OflxVlfU0x699Xv1LtSaigFAKAUAoBQCgFAKAUAoBQCgFAeW1vWpIdSS IRIyWspYxbzvkxESGK44QEjnzWt4Y7jfn+TCeSpV5Gi9p7oySMY7IQL7gmMrCLcC+Tvx0IUAevn4 z3KI75m8utyi8iuk7lYpLWMN30zLHBIxZmDYGM+6B55x51Cxqq9Q8ju/QP2lupcLb2sccjMn7KVi ZEGUyWUDhSGIB88euCxJcsd63wjEXaa4uoVMMEXvx94ZIZC4QYzs5X4xkZHr9KnuknuFlbWxk9oN Ra4jRLKAbyBtLtj32UISdvGMkkfao7qNcjvZXwRSdqL6dhFaWCJK3dbRLJ/EUzkddp3kA48M+lSs MVu2Hmk9kiaPtK20rBpvs8QIPeTHYiKx27m4498OD/0g/vCo7rzZKy+SNDrtzNe2Mxh7q3MjRvh2 28op3tx8PIwfUZxU92kmiO8bafQnue0Hs080dnawOu7ChXwzEgHvCAPgJON3PP4VWO1uyXlpukWt H1l9QvpraSKJCkYfCSEsnvFdrggYPGfr9TE8elWWhk1OjtVkaigFAKAUAoBQCgFAKAUAoBQHyXtN A8naa/tZJVL+0JcxRtxI4AB2L/EDgEY8VxXo4n/rT+R52Vf7Gj0f6PNdutVsX06/mka4jgDiYn3w CzLg+owOtYdoxqD1Lg37Pkc1pZ6NNFij/wAO5ulAQIoEnwr5fKse8fkbd2l1JF0pRwbu6YYwcyfj 6VGv0J0epGukblkS4uZpEMoeP3jlcDHX+/Cp1+SI0ebN20pWjRTczlkZmEhbLc+GfKo1+hOj1B0o Esfa7rk5A7zgfTypr9Bo9TL6UskSxSXNwyhmY5f4s+B9P9aa6d0NG1WJNLVpJWW5njWRtzIhAGeK KfoNHqarpCqhUXd1/lPedBTX6DR6mF0WLaVe4uHBOeWHiOfDxqe8fkR3aLlnA1vAI2kaQgk7mOT1 6fQcfSqN2y8VSJ6gkUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQCgFAKAUAoBQGMDGKAzigM FQQQR1GDQGsEMdvCkMK7Y41CqPIAYFS3bshKlSN6gkUAoBQDFAVLPT7Wzd3t4irOACSxbAyTgZPA yTwOOas5N8lVFR4LdVLCgFAKAUAoBQCgFAKAUAoBQHl+3ul291pMl6+5bi2XKMuDnnoQQR+db9nm 1KvMwzwTjfkTdh4GGixXc1xLcXFwMtJKQSADgAYA4qM78VLoMC8Fs9FWJuKAUAoBQCgFAKAUAoBQ CgFAf//Z --=-=A8lNZqNxebGArEOA2g_DEM4bbUcV8TbYFNf0=-=-- From nobody Fri Sep 6 21:46:00 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 4X0qY53zD5z5W3xQ for ; Fri, 06 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@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 4X0qY51NwGz4BGB; Fri, 6 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725659161; 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=MRMhe9nzuHXBqsPJ0khEyMDZr9dF4Md8il/sZSmnV2E=; b=pDXnwSdEuYiDKo9ygaPCVnMNT0/x1KY3WtnBRMHht3RTUWuAjLIp8Q9nJBlc1O85wWu+Yv cn7dzdO99ErKBULiM4ANHmNx4MArQdim5nbQsw7UuQIP0RIXpfHd3dl565WhFCVp/ghZqV bgq4djPtj7OIkKnXQvjcJ7FJfxQss2cl7+5oWLmIHL0Km6mrSibsZO1ISIHh4J6pONnf3O tP6G+L8PqqytswtKow2ab23eYeyI5t4pTizcxuIVbeLsA4nhBDkTy8EYzFusmkTD2xno4A tCSSr/tF+fc+J+h4nBZ+d8e8wTqhK7k6dU3pwfKnMQ2C+6U2irRmV3pz1E+Uuw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725659161; a=rsa-sha256; cv=none; b=mllY0FsqP3iY/QuYHogjhCKA1Ota58r2ZXdZtteWKvHRxu+Muj1exx3wYVDAajNob0n7qn VFe6Dknfq8kVUlpdWVv73V9nCg8JVwaQXn3ax7dh801+KjwG54vNELC7SdSz/xg4dCPbWW aX+FmH9JiNOewD7w+IujDE6dDnYWIOruS0v5Aj1/8k79/vhuGlcZ71MvIei1piPPEcI1zv wIhXagobR1MHTcX/xaLsD8V54Yj0HR68hKMaKF2DY9MKLFjrOMjMLvXW8E407xkVCmuz4l wequ7B+b6saGvIRCAnq3AdvQOjA8ns55zAbya+OdczXsUgfxhkKXh3s97xwxEQ== 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=1725659161; 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=MRMhe9nzuHXBqsPJ0khEyMDZr9dF4Md8il/sZSmnV2E=; b=Vhhayhrv1Q8WrKQcxhonNBThp2WXoSy/698zoQtAiSGQPBdjtfrYDh2/3mMf4wMEV4BpF9 mtUY5wgv9ZB8wQ369xnxjn71BLr1iLpzJOXheo+QwzxOX75q7QDeprZVABwq7qpj/pIpz3 Bl7FW3f4sp0P7q1dcwervzEjiA/qGh3RHgi/SRDLdyNxT08ygEOKqyCqDKsFqEokXfc0IB u8H2JwRGbJjDIfaRQsokeX/2LLP2OyB5qsM60f69n3j/LPDjE0ze8YlQLL9L9ZCvnVsoMj pyUFYvUMd41+ZxZGkpvLeHtTb5jYQf6Nn1dYO5W0PpQS7ahGnzchB0tT0Wb8sQ== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0qY50l6TzbDn; Fri, 6 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 682E23C019B; Fri, 06 Sep 2024 21:46:00 +0000 (UTC) Date: Fri, 6 Sep 2024 21:46:00 +0000 From: Brooks Davis To: Alan Somers Cc: FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Sep 05, 2024 at 12:09:18PM -0600, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. I broadly agree and think that as a project we need to be willing to take some risks to move our development towards more modern solutions. Part of that likely means bringing kernel and userspace componants built in Rust[0] knowing there will be some integration bumps along the way and understanding that Rust may or may not stand the test of time to the degree C has (meaning burden or feature loss down the road). We need to move forward and all paths involve some risk[1]. While bugs you can't write because the language doesn't let you are the best bugs, we should also be looking at deterministic ways to improve our C and C++ memory safety. In my biased opinion, our most realistic option for making major advances here is the adoption of CHERI[2]. We've got Arm's Morello prototype today and we expect commercially available RISC-V silicon in the next year or so. At this point I hope to merge CHERI support from CheriBSD[3] in time for FreeBSD 16 (subject to standardization timelines, funding, and hardware availability). In the meantime, we should be looking at orthoginal techniques such as enabling default initialization of stack allocations. While the current state of affairs is quite problematic, we do have time. Regulators are aware of product lifetimes and realistic timeframes. We can afford to be methodical and not chase every trend, but I don't think we can afford to stand still. -- Brooks [0] Other languages might well make some sense, but I'd argue that we should not generally be adding languages that don't have clearly growing developer communities so some languages mentioned elsewhere are obvious nonstarters. [1] This includes the choice to continue as is. In particular, regulatory risk is hard to predict. [2] https://cheri-cpu.org [3] https://www.cheribsd.org From nobody Fri Sep 6 21:47:59 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 4X0qbP3Hzyz5W3ZZ for ; Fri, 06 Sep 2024 21:48:01 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X0qbP2ZKsz4D6y for ; Fri, 6 Sep 2024 21:48:01 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725659281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GUiAZMGlVSbF9G81VNlkvbMoWJcsRsNgKP53EHCgnXQ=; b=Qx29DgFmmnSfbGHfGeWz2pxn4fMWAEVA3ZTziFzpYdmk9FVXKsyMEaN1T07mApQl2dvPyS UfAjHIwugdpazsGCd/Xh7KMBY8Ml4ayQOrjdTRjVJajzAyK5aEcROxzMowiGGTWrUxVQv/ iS+adUPXtGvhmLQifnLlD5MMJwMGX5nihRYDoqoWFPGgfZRKqTCj8DvYc4ujc2QhBp0fSh IOhRgV0gRA2NoF6O8n7/tbpxQtM/w3S5WZC3iBxk1hvl6kz6foMhvSzTUpOg9uRweInruL x+cieO3d+Z+mh+uYoz1pwI+k2mtnXNp/f+kowvqxa5VA++Um4T/+FW9yQyhFyQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725659281; a=rsa-sha256; cv=none; b=qzOSOvyJMuGhGjeet58w3JDuvmEQfaddPCH6knlc5Q8iTJmlyucKVkJ1qQfj9AmqylWIt+ rhQSwGiwdNdp1NF5yf21EmrnJIlDBURdbcslMSq6l9EV9l2UWap5gTvin40NN9Mu025FUK zj5oUPzApP1CPoMHLVEmMYpHlYpTVY2yKH2pv0ZxlNVywkqUyR+3MNOIiCS2EFaFFhaNxe 0Gjf0U6Y8Jv9HkJEth6sx2Y05NwIVRD/JGobumWFH3Oz7nsWBuFLIM3l6ok4oPX/s/s+hW Xpu3LcTaTrdFdViWbZELqatsq+TPUvq5bDQpsz1PQ1SnCEZ7Xkv+ntdtNGl4Pw== 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=1725659281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GUiAZMGlVSbF9G81VNlkvbMoWJcsRsNgKP53EHCgnXQ=; b=cp42GvJgqGxrv7/Z/K/t+ZQkAz9oz5cdG5yqMb9teHIfdy/7D5yP1LI6JtOoEGHsj3hWDb A3fubj6yEep0Uwg4Xe2LG8id1j+ngQBqNxREV3KuZ1b4/Ai3yMoLXj/m1ohQls6NM8434J Qi9JQwhrgp24ofwwo12RlHNV5PXl1RnMdt5rrSTNOgIb8bW9vegCR3CgKwP7VbcDRMbpVK 4oN8nT37BOAYHA6XBnEu3iYsXr1WgXmVWfM1XaJqq2qbQ59vFPYImqrfTD8TyLbZCD1rF1 oi1/rIMPavVW6puU2QM7zZcB1xVwvNVUyb+x23r8vceIoJ9pDrjO7OE/DLXYSQ== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0qbP0sxRzZHt for ; Fri, 6 Sep 2024 21:48:01 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: Date: Fri, 6 Sep 2024 14:47:59 -0700 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 User-Agent: Mozilla Thunderbird Subject: FreeBSD+samba as a time machine server for OSX/Sonoma? From: Craig Leres To: freebsd-hackers@freebsd.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Last year you guys helped me get this to work with samba416. I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is "The backup disk image could not be created" and I'm running 14.1. I'm using the same port build options with 4.16 and 4.19: FAM PYTHON3 QUOTAS SYSLOG UTMP GSSAPI_BUILTIN AVAHI FRUIT Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on the server before starting. I've also learned the rule that you need to delete and reattach the share on the mac side when you change the samba config. Appended is the config that works with 4.16 (but not 4.19) Craig [global] workgroup = XYZ security = user netbios name = red server string = red.example.net hostname lookups = no server role = standalone server interfaces = ixl0 lo0 bind interfaces only = yes load printers = no show add printer wizard = no time server = yes use mmap = yes dos charset = 850 unix charset = UTF-8 mangled names = no #log level = 3 #log file = /tmp/samba.log vfs objects = catia fruit streams_xattr zfsacl fruit:model = MacSamba fruit:resource = file fruit:metadata = netatalk fruit:nfs_aces = yes fruit:copyfile = no fruit:aapl = yes fruit:zero_file_id = yes inherit permissions = yes [Time Machine] path = /backups/mini read only = no guest ok = no writeable = yes browseable = yes fruit:resource = file fruit:time machine = yes valid users = backup-mini max disk size 512G hosts allow = 10.0.0.19 From nobody Fri Sep 6 22:27:05 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 4X0rSl6s5lz5W7gj for ; Fri, 06 Sep 2024 22:27:19 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0rSl25Hrz4LSd; Fri, 6 Sep 2024 22:27:19 +0000 (UTC) (envelope-from joesuf4@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=d4ZAaA60; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of joesuf4@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=joesuf4@gmail.com Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-374c1963cb6so1379801f8f.3; Fri, 06 Sep 2024 15:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725661638; x=1726266438; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zUh2QzJSSq+9WtMqqYk3HCZKW9db5YSPlNVT8BW/9aM=; b=d4ZAaA605HdXGICSBZFbjhZsPye/SAi6ZmgomQLnHBtPxC1+sms8OoVTMzXUf1U1p5 9Ap5PCvSSWGnroKWAKWT5oPYWahH1HNOmNX5aKKJuiWGS10Qs39PKM3w1vauJtnHpJ0V J8mAxJLQY3QJ8aD8eMTk+qH6zoNGuNsgOFxOYHbfG5tCWtqQXWslbnw6uDcdgd9ErRZ7 EiLiNwZEAR7YLD+H+LGVlfZxxElk9KxZm86iiKbGpR2DPXOnYWZQ3jr9yRUpPLI30IV8 PPo0tNPVgp+FaIOpwa0LMvZVt0QKQmqHGbbQL/6KUUJDuDbCDO9R2mEBz/CEW2q+Gpfc oFGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725661638; x=1726266438; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zUh2QzJSSq+9WtMqqYk3HCZKW9db5YSPlNVT8BW/9aM=; b=PTESfOzABzXp58gp4E810PZ4e50xUhG+RhXWu5rR36ksKyecS5vcliMtVUsgAeW5V8 gVvNy0a72imIEntXOZaK6ULFWe2F6lT4ASLPXW5BhjsIQhstU9BTW/TtSS9C3Y7kbI5L se0CctzcGXaiFsGxLQmpg13Ex7FYT44ji9r3FFJI4l1yAPoFIjm214QJDzFzqq7dHBYR 2QZbLPaY58R+Lpo4n9ghTrLYUhfzzEyYhazLFUrYslsI4EQcKyM9ktk+BmmJZBRwCIpG 1Hp1u9cW9kMtyU/iWGYjvOVOJXC5ydoEFpVcztYVOVa3JAyGDuFFdOCfRuJZRxOCztqK P7jg== X-Gm-Message-State: AOJu0YzkDhS30OTRNl94qMKY9Q3sPbrxuEJgQzdoQetj+KWMUWocJ5Iv xUadUL3hbfenQew4jrZVV0yCbNDplA4k2i2kC1f+C8VuBAZpmpvMcSb45X9CQJ4zxkICSesyZWF z/oZia6kCb0+vd1EiyN8ZW4plv/OSiw== X-Google-Smtp-Source: AGHT+IH4qI/Dlv/0uOB3s0YOaXCZrdBuv9iWQ9aC/EidOOScJu2vo5/IENyh+A0fx5Ro5imd3f7HP0kUqZLKaxZe4UE= X-Received: by 2002:a5d:6905:0:b0:374:c454:dbb3 with SMTP id ffacd0b85a97d-378896a00b4mr2200371f8f.55.1725661637152; Fri, 06 Sep 2024 15:27:17 -0700 (PDT) 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 References: In-Reply-To: From: Joe Schaefer Date: Fri, 6 Sep 2024 18:27:05 -0400 Message-ID: Subject: Re: The Case for Rust (in any system) To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e299b106217ae812" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.25 / 15.00]; HFILTER_URL_ONLY(1.75)[0.79701952723535]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::436:from] X-Rspamd-Queue-Id: 4X0rSl25Hrz4LSd --000000000000e299b106217ae812 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What a goofy thing to say. On Thu, Sep 5, 2024 at 2:09=E2=80=AFPM Alan Somers wr= ote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: > > Buffer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D3aaaca1b51ad844ef9e9b3d945217ab= 3dd189bae > CVE-2024-45288 > > FreeBSD-SA-24:09.libnv > > https://cgit.freebsd.org/src/commit/?id=3Da06fc21e770a482c8915411ebc98c87= 0e42dd29b > CVE-2024-41928 > > FreeBSD-SA-24:10.bhyve > > https://cgit.freebsd.org/src/commit/?id=3Daf438acbfde3d25dbdc82b2b3d72380= f0191e9d9 > CVE-2024-42416 > > FreeBSD-SA-24:11.ctl > > https://cgit.freebsd.org/src/commit/?id=3Ddb87c98168b1605f067d283fa36a710= 369c3849d > FreeBSD-SA-24:11.ctl > > > https://cgit.freebsd.org/src/commit/?id=3D5c9308a4130858598c76f3ae6e3e3df= b41ccfe68 > CVE-2024-32668 > > FreeBSD-SA-24:12.bhyve > > Integer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D36fa90dbde0060aacb5677d0b113ee1= 68e839071 > CVE-2024-45287 > > FreeBSD-SA-24:09.libnv > > https://cgit.freebsd.org/src/commit/?id=3Dc3e6dfe55c0e81d0717b0458bc95128= 384c3ebe8 > FreeBSD-SA-24:14.umtx > > > Use after free > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D670b582db6cb827a8760df942ed8af0= 020a0b4d0 > CVE-2024-45063 > > FreeBSD-SA-24:11.ctl > > https://cgit.freebsd.org/src/commit/?id=3D62f40433ab47ad4a9694a22a0313d57= 661502ca1 > CVE-2024-43102 > > FreeBSD-SA-24:14.umtx > > Uninitialized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3Dea44766b78d639d3a89afd5302ec6fe= ffaade813 > CVE-2024-8178 > > FreeBSD-SA-24:11.ctl > > https://cgit.freebsd.org/src/commit/?id=3D0f2b2276abc305905e7d88619a7abca= 26b0dd7eb > > Memory Leaks > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D2909ddd17cb4d750852dc04128e584f= 93f8c5058 > > Incorrect union member access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D9a5a7c90d5e5971fe2b9c9265e9279a= 6f173a8f3 > CVE-2024-6119 > > FreeBSD-SA-24:13.openssl > > Concurrent unsychronized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D1f5bf91a85e93afa17bc9c03fe7fade= 0852da046 > > RAII > =3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D4b3141f5d5373989598f9447ab5a9f8= 7e2d1c9fb > > Unchecked errors [^1] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D35f4984343229545881a324a00cdbb3= 980d675ce > > https://cgit.freebsd.org/src/commit/?id=3Deced2e2f1e56b54753702da52a88fcc= be73b3dcb > > https://cgit.freebsd.org/src/commit/?id=3Df625d038d2ae59fa1ae81b76079da46= 4ed6db61a > > Not preventable by a safer programming language > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > https://cgit.freebsd.org/src/commit/?id=3D7d6932d20aedbbb220cd78e90ab4e82= d1abaad31 > > https://cgit.freebsd.org/src/commit/?id=3D6efba04df3f8c77b9b12f1df3e5124a= 7249b82fc > > https://cgit.freebsd.org/src/commit/?id=3D4b72bab96e8978eaed30fd44f7f51e1= b4918d4db > > https://cgit.freebsd.org/src/commit/?id=3Db64afa41d56e98b5817aaf14c7deb0f= a7e2142fb > > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. > > --000000000000e299b106217ae812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What a goofy thing to say.

On Thu, Sep 5, 2024 at 2:0= 9=E2=80=AFPM Alan Somers <asomers= @freebsd.org> wrote:
By now = I expect that most of you have seen the long list of new
security advisories that just came out.=C2=A0 Strikingly, all were the
result of memory handling errors.=C2=A0 And none of them wouldn't have<= br> happened if their respective programs had been written in a
memory-safe language.

In fact, of all the C bug fixes that I've been involved with (as
either author or reviewer) since May, about three quarters could've
been avoided just by using a better language.

The real takeaway here is that C is no longer sufficient for writing
high quality code in the 2020s.=C2=A0 Everyone needs to adapt their tools.<= br> Programmers who don't will increasingly come to resemble experimental archaeologists, i.e. people who learn flintknapping to "keep the
knowledge alive".=C2=A0 Such people are valuable, but definitely niche= .=C2=A0 I
for one don't want my career to go in that trajectory.

To summarize, here's the list of this week's security advisories, a= nd
also some other recent C bug fixes of my own involvement:

Buffer overflow
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http= s://cgit.freebsd.org/src/commit/?id=3D3aaaca1b51ad844ef9e9b3d945217ab3dd189= bae
CVE-2024-45288 FreeBSD-SA-24:09.libnv
http= s://cgit.freebsd.org/src/commit/?id=3Da06fc21e770a482c8915411ebc98c870e42dd= 29b
CVE-2024-41928 FreeBSD-SA-24:10.bhyve
http= s://cgit.freebsd.org/src/commit/?id=3Daf438acbfde3d25dbdc82b2b3d72380f0191e= 9d9
CVE-2024-42416 FreeBSD-SA-24:11.ctl
https://cgit.freebsd.org/src/commit/?id=3Ddb87c98168b1605f067d283fa36a710= 369c3849d
FreeBSD-SA-24:11.ctl
http= s://cgit.freebsd.org/src/commit/?id=3D5c9308a4130858598c76f3ae6e3e3dfb41ccf= e68
CVE-2024-32668 FreeBSD-SA-24:12.bhyve

Integer overflow
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http= s://cgit.freebsd.org/src/commit/?id=3D36fa90dbde0060aacb5677d0b113ee168e839= 071
CVE-2024-45287 FreeBSD-SA-24:09.libnv
https://cgit.freebsd.org/src/commit/?id=3Dc3e6dfe55c0e81d0717b0458bc9512= 8384c3ebe8
FreeBSD-SA-24:14.umtx

Use after free
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http= s://cgit.freebsd.org/src/commit/?id=3D670b582db6cb827a8760df942ed8af0020a0b= 4d0
CVE-2024-45063 FreeBSD-SA-24:11.ctl
http= s://cgit.freebsd.org/src/commit/?id=3D62f40433ab47ad4a9694a22a0313d57661502= ca1
CVE-2024-43102 FreeBSD-SA-24:14.umtx

Uninitialized memory access
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
https= ://cgit.freebsd.org/src/commit/?id=3Dea44766b78d639d3a89afd5302ec6feffaade8= 13
CVE-2024-8178 FreeBSD-SA-24:11.ctl
https://cgit.freeb= sd.org/src/commit/?id=3D0f2b2276abc305905e7d88619a7abca26b0dd7eb

Memory Leaks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://cgit.freeb= sd.org/src/commit/?id=3D2909ddd17cb4d750852dc04128e584f93f8c5058

Incorrect union member access
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
https= ://cgit.freebsd.org/src/commit/?id=3D9a5a7c90d5e5971fe2b9c9265e9279a6f173a8= f3
CVE-2024-6119 FreeBSD-SA-24:13.openssl

Concurrent unsychronized memory access
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://cgit.freeb= sd.org/src/commit/?id=3D1f5bf91a85e93afa17bc9c03fe7fade0852da046

RAII
=3D=3D=3D=3D
https://cgit.freeb= sd.org/src/commit/?id=3D4b3141f5d5373989598f9447ab5a9f87e2d1c9fb

Unchecked errors [^1]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://cgit.freeb= sd.org/src/commit/?id=3D35f4984343229545881a324a00cdbb3980d675ce
https://cgit.freeb= sd.org/src/commit/?id=3Deced2e2f1e56b54753702da52a88fccbe73b3dcb
https://cgit.freeb= sd.org/src/commit/?id=3Df625d038d2ae59fa1ae81b76079da464ed6db61a

Not preventable by a safer programming language
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://cgit.freeb= sd.org/src/commit/?id=3D7d6932d20aedbbb220cd78e90ab4e82d1abaad31
https://cgit.freeb= sd.org/src/commit/?id=3D6efba04df3f8c77b9b12f1df3e5124a7249b82fc
https://cgit.freeb= sd.org/src/commit/?id=3D4b72bab96e8978eaed30fd44f7f51e1b4918d4db
https://cgit.freeb= sd.org/src/commit/?id=3Db64afa41d56e98b5817aaf14c7deb0fa7e2142fb

[^1]: while not memory-safety bugs, Rust's lints actually make
ignoring errors like this pretty difficult.=C2=A0 So I consider these bugs<= br> to have been preventable.

--000000000000e299b106217ae812-- From nobody Fri Sep 6 22:31:52 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 4X0rZG2Crpz5W89n for ; Fri, 06 Sep 2024 22:32:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0rZG0SRBz4Mwv for ; Fri, 6 Sep 2024 22:32:06 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-49bdc6e2e2cso448189137.0 for ; Fri, 06 Sep 2024 15:32:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725661925; x=1726266725; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p24wlpaZViNFa+qvwkRA8C1xu36KSWFWT+5y6J6SI/g=; b=KCpMYhZq/Urzbu6HAvVjppzI4xpK7OcI/bY7dBGeB7GQQ47tJ/gyZcUE/jwBtZIl/Z lEkMNbty0BljllLdDSD4d8VYf6YXqSIENTSdTDqiXazNiDi8OZqqsVtR+/rCAFpNqXEe 9bLccblptoiqOPKYxCNyjqH14iM4N82Yld3rQytAOCQRheuONnUKcrlUxk1yyoaa+eNy rQnRfvX+TK9jWh2vFYlMspSQEVxgdQ5HvL1nzfaAUkKNySftaPwHOHfDdn/VMoNq35kk 0+s4aF0p47zh7bZP7mINgtDqoF+nNJBbmC7Pi3dCqx3ii9dhWp5+BjkDnRfq/XCmwj0d 92WA== X-Forwarded-Encrypted: i=1; AJvYcCWUtkYLGNd/DihJ6SLA9nauas23wrivjpMmo6Qy+vEyEi3z9CCR9G2b44I6Zb/gzDuKTQm/SWxQoB5r2ZdW6AY=@freebsd.org X-Gm-Message-State: AOJu0Yyuc/k/C50VP83inTDLN/detRE2b2pm7qugtwjRSwgCP3pwF9dK F46evmsyXipC2xVTvP6eNDjAJEhhIls56UaJE0dJUBu/i1vjFGSy3dqnG8SIqCOYXW+x33ORhTw tgb7/8VPsg2FYLs2HodWN1/f8Insuk0F5 X-Google-Smtp-Source: AGHT+IEKOwvfdzVmdCq5n9npTKY45TpGZ/JlK3OXq0q1ovROTkd+f1U8PS/ds88NI5azrYAoO377PD9zud12irIcGG8= X-Received: by 2002:a05:6102:e07:b0:49b:dfaa:c76a with SMTP id ada2fe7eead31-49bedb74571mr613318137.4.1725661924981; Fri, 06 Sep 2024 15:32:04 -0700 (PDT) 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 References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> <20240906210711.RUo97_0A@steffen%sdaoden.eu> In-Reply-To: <20240906210711.RUo97_0A@steffen%sdaoden.eu> From: Alan Somers Date: Fri, 6 Sep 2024 16:31:52 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Steffen Nurpmeso Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X0rZG0SRBz4Mwv On Fri, Sep 6, 2024 at 3:07=E2=80=AFPM Steffen Nurpmeso wrote: > > |>|/Kristoffer Eriksson > |> --End of <202409052313.aa18097@berenice.pkmab.se> > |> > |> In support for that swedish hm virgin, yes, sweden is not a clean > |> country for sure. > | > |Again, I don't know what you mean. But it looks like a personal > |attack to me. Please try to keep your discourse on the public mailing > |lists respectful. > > I cannot understand how you come to the conclusion the above was > addressed to you; it referred for example to the attached picture. I apologize for my ambiguous grammar. I meant that the comment looks to me like a personal attack, not that it looks like a personal attack against me. I should've said "it looks to me like a personal attack against Kristoffer". But I still don't know what you meant by it, and the attached picture did not help. From nobody Fri Sep 6 23:22: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 4X0shV0D0xz5WCqf for ; Fri, 06 Sep 2024 23:22:34 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0shT4sKxz4TmW for ; Fri, 6 Sep 2024 23:22:33 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725664950; x=1725924150; bh=jqQ0qUyOY/UmyqydYVg2qaLdOZOKwcyaI/3YGB7B20Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XZBhn9BI/rqX6bQeo7wtkN4QeNkOGFs+GMZnTbDcFtahplUg8lw5WIqo+5rYHQ0K9 j+9ogtUpAFXau0OWCbPZnxhjsT08PW9miJYEewU3icXRtePUknJzLrWNyUpmu1iGIE pkb5lUfFgaVXGd74fsWd9Tn9oBJVa12iS8RK0UCQvl0FFLlRocg1KXeq7MIBHX32Fl 1nVTEd0F6QTYJNGKPVDPimyaWwJrYqnJDFSOPNXQaOdWzAs7ofVpFCBFE+dIYLBf0y x0R14sJ6HdLXblJ31bsRTmX0lqxqD0v7uzA4FY4SVy67Z/bhidXUkHWX1CCF8rj5Y3 COq54pARjSCtA== Date: Fri, 06 Sep 2024 23:22:26 +0000 To: "theraven@freebsd.org" , "asomers@freebsd.org" From: fvalasiad Cc: "dsl@freebsd.org" , "jan@digitaldaemon.com" , "freebsd-hackers@freebsd.org" Subject: Re: The Case for Rust (in any system) Message-ID: In-Reply-To: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> References: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> Feedback-ID: 78761413:user:proton X-Pm-Message-ID: 4461d5b71164f55439b502e2177de906af3d70b7 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4X0shT4sKxz4TmW Personally I've started enabling Wall Wextra Wpedantic and fanalyzer in my = C projects' repositories. Facing the exact same issue with fanalyzer, known= as false positives, I've chosen to refactor perfectly functioning code to = eliminate said false positives and avoid having legit bugs that could have = been found by static analysis hidden by a backlog of magnitudes more false = positives. Would that increase development time? Yes, but does it cost more than switc= hing to rust? Fotis -------- Original Message -------- On 9/6/24 10:02, David Chisnall wrote: > On 5 Sep 2024, at 22:13, Alan Somers wrote: > > > > I used to check it, years ago. But I gave up. The UI is too hard to > > use and false alarms are both too frequent and too hard to suppress. > > Plus, it's a real drag that I can't run the tool myself. Instead, I > > need to wait for the next scheduled run. > =20 > In general, it=E2=80=99s very hard to add static analysis to existing pr= ojects. The property that you want is that there are no *new* static analys= er errors in a new commit, but that=E2=80=99s requires tracking all of the = existing ones. In CHERIoT RTOS, we run the clang analyser in CI as one of t= he checks that must pass before a PR can be merged. This is possible becaus= e we started doing it very early on. It may be possible for some individual= parts of FreeBSD, but when we started with Coverity I looked at the report= s and the first ten I looked at were all false positives. There are probabl= y some serious issues in there but the effort to find them is high. For a n= ew project, that cost is a small incremental cost in each commit and code r= eview (if the analyser finds something, reviewer has to agree that it= =E2=80=99s a false positive). > =20 > David > =20 > =20 > From nobody Sat Sep 7 01:41:12 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 4X0wmg34LKz5WSHk for ; Sat, 07 Sep 2024 01:41:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0wmf5V56z4hS3; Sat, 7 Sep 2024 01:41:22 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725673274; x=1726339940; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=+R80MCpQkFc4v9F46OsXFEqs7igL0GcBUtXCXYjevo0=; b=D1lUluj8sQ++zryYKUx4dr6dTNcxoM49xjuFdRxhqaroRkZ9+S+r+XJkdduC6kE2qI1dxuKh AOmTEmxTfJxjmO+adD8snYIySwJnyWeWmWGvy1JVf0qL+kr3OTAEHOhMPJ3Q8ZjMlgdFJzyudm M1DlEke8Kr98aI10dABgejHN2+6+txVmZuxVWg5ugClXYOjJOOF8E1TYUHuVQ2Gnwc0Lj6+taM aOOUNV4tJ5Msq7kxUHKRHUEet8sozUqboMfjcA9hWmeuOu//uTNHTwetR0U+EAowiEXB1wJalY nVFWzBjz0FNkoAghQtNt6U/6xMcmyY9DTLMdTVxAV57pNJ5Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725673274; x=1726339940; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=+R80MCpQkFc4v9F46OsXFEqs7igL0GcBUtXCXYjevo0=; b=ISymiwoTfVhy44LSIXTwCjgA71znMAw+pgsu0eGUKcYDffDzDAeD5Ac83MoKUeOA+OP3sQtw YTJ2825BClefAA== Date: Sat, 07 Sep 2024 03:41:12 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Alan Somers Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240907014112.aSCgFO0F@steffen%sdaoden.eu> In-Reply-To: References: <202409052313.aa18097@berenice.pkmab.se> <20240905225129.UvYYMXDa@steffen%sdaoden.eu> <20240906210711.RUo97_0A@steffen%sdaoden.eu> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X0wmf5V56z4hS3 Alan Somers wrote in : |On Fri, Sep 6, 2024 at 3:07=E2=80=AFPM Steffen Nurpmeso wrote: |> |>|>|/Kristoffer Eriksson |>|> --End of <202409052313.aa18097@berenice.pkmab.se> |>|> |>|> In support for that swedish hm virgin, yes, sweden is not a clean |>|> country for sure. |>| |>|Again, I don't know what you mean. But it looks like a personal |>|attack to me. Please try to keep your discourse on the public mailing |>|lists respectful. |> |> I cannot understand how you come to the conclusion the above was |> addressed to you; it referred for example to the attached picture. | |I apologize for my ambiguous grammar. I meant that the comment looks No need for that. (In general, to me, these so-called social guidelines appear strange to me in hindsight to what our society, not only the western, but that the most, of course, de-facto has done, and is actively doing.) |to me like a personal attack, not that it looks like a personal attack |against me. I should've said "it looks to me like a personal attack |against Kristoffer". But I still don't know what you meant by it, and |the attached picture did not help. Well maybe it in the end was aggression under the hood even. But that not consciously and definitely not anti-persona. If it was then likely because of the thread i should better not have anticipated in at all. Well, yes, a headline of "not preventable by a safer language" is indeed almost complete bullshit, and it maybe was the funky "get the quick meat" a la pacman in return that cause the reference to Greta Thunberg, aka to the reality under the carpet. Btw looking again at https://marc.info/?l=3Dfreebsd-hackers&m=3D172557576903954&w=3D2 of yours i am still totally unimpressed except maybe for "Circular references are almost impossible to create due to the lifetime borrow checker" given how deeply inter-referenced several complicated objects i have encountered by the occasional look into kernel systems (VFS was mentioned) are. I could now give exact counterparts, this thread kills the last midsummer day for me, tomorrow, i will not be in bed before 7 o'clock in the morning, what a mess. But *everybody* who reads this *knows* how to address the problems we are talking about. Ie unions, if used like that (?), can be solved by an outer struct with an ident field, and you can test that (sockaddr). More data, more (at least debug) test(macro)s. There could be a barray or bvec type with accessor (inline) functions. "Zero initializing a structure, but with the wrong size"; then use macros or inline functions like TYPENAME_init etc, which do that right, instead of memset(PTR, 0, SOME_SIZE_I_GOT_WRONG_BECAUSE_IT_IS_LATE) or something in a thousand different places. Where is the problem? That it is not done, that is the problem. Etc etc, you know all that. Why this other planet Rust. Ah na, like Pink Floyd's Animal Dog You gotta sleep on your toes, and when you're on the street You gotta be able to pick out the easy meat with your eyes closed And then moving in silently, down wind and out of sight Which brings me back to Miss Greta Thunberg again. --End of --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Sep 7 07:28:48 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 4X14Tn2x8Fz5Tq79 for ; Sat, 07 Sep 2024 07:29:01 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X14Tn2M2tz48d1; Sat, 7 Sep 2024 07:29:01 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725694141; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4JyuolmzGpDZmw4UP0VhQo3M8EOZceOrGCNxjN1jWiY=; b=pYsjx5a3neTciLOLjTlaNpQAswiL5oNq+KZhxkLOUwS0bNBwnfHO3ZdDR7P8NYdVNa2M+M J4Z4fDCmfpsARmeg4ITXA6mCor1gxORh7Xxi5CZuV0hUhc2aChPnSlX7MOd5bMXEF8m4hQ G4iKPIVGoixZRC9B0e9PVfPkF91q9StD+BwEk2RSer6CT90wb34qBNk2acyCeaX9C2TLbS dMdlQAKx85PWl4AWZ4k9w58iClOoqaoc34GofIn5E9OtApB8ILAC9y6T3Po4v/ROo918do HNhSThW63/he5WysZvjQxbkpLs1cIt1d0xL7b4iNSU38cbYyxS+VqrDeMFdD2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725694141; a=rsa-sha256; cv=none; b=aBk0jBIxupWIAOZkHOEbAHCIirzWjFn4nqJ4/GCthaHJ/sZl/sVj0gR3rNC/svP8v34Zn3 P0SDhrnHN4vYT9yW6uocGMPYSoPNKZA4iEq1XxeTC9V9xXTA7K0CRJllazt6ISAuqzKSHw NT6zxwudi1Y4/tRGO8IJQ0kWhycM0wvzGJ5Jb60vZD1Q/h7ScPs1wAXa66Ybc9PBxAU650 IDB1MboIvNkp4iJMU7EgLiw7cDgNLmbwWj7zvBHP6H9RNLYQTqjxxrEIRukwNW4V5es1KT 7ka6b7xVHSG144Dn43/xwHb5DSvp4LBzKtT5Qu3W8rXlzv/pVxhmcEYlemFQ9g== 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=1725694141; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4JyuolmzGpDZmw4UP0VhQo3M8EOZceOrGCNxjN1jWiY=; b=FA9bQHhCeebYAshdrHzMfhZa9ZCSvkaAspSJ3F/yK0fHi/M1+t+2pl4kEZ8dCtJXZCDu6I TWXg7lOhMcaNv/0suNyOHgkifPv0JCxztVbw9SB6B8VYrEIiNye6Rldx+Tn6zvj7qTBwdg nrNyEi67+J0XXuNX93bHsw5Ptjer3snOFZ91VUPnOCascNE1xE+uoZ7TH6IDvXL4XU2q5H P1MEeHzwX1v0yyIpCWVMjPjcvmdBIkCTVwO3vIWa2LZ8ZXFoV6DuIyHDj3VN8m8wBoxFX5 WGYb2TdOznMH0SlOLlR3AgBMcFmG+R+JjpGeJcBNjzfaSvLL5rU0mrQhbvUuYQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X14Tn1nx8z11RB; Sat, 7 Sep 2024 07:29:01 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 19E1D6531; Sat, 07 Sep 2024 08:29:00 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sat, 7 Sep 2024 08:28:48 +0100 Message-Id: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> References: Cc: freebsd-hackers@freebsd.org In-Reply-To: To: Craig Leres X-Mailer: iPad Mail (21G93) --Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe this was broken by a macOS update around February. I=E2=80=99ve be= en trying to debug for a while. I=E2=80=99ve opened an Apple issue (FB145009= 50, for any Apple folks) but it shows up as few people reporting it. I poste= d on Mastodon and several people reported that Time Machine is broken and re= commended Carbon Copy Cloner as an alternative. I would like to see it fixed= , but it probably needs some more debugging by Apple folks.=20 It stopped working for me with no changes on the server and I can reproduce t= he failures on two different Macs. Things I have tried: - Upgrading Samba from 4.16 to 4.19 - Upgrading FreeBSD from 13.x to 14.1 - Setting the SMB timeout sysctls to larger values on macOS. - Turning up the SMB debug sysctls on macOS to see if there=E2=80=99s more i= nfo - Turning up the Samba logging level. - Verifying the backups - Watching smbinfo the server. - Updating macOS to the latest version - Connecting to the server with Finder and checking I can access files on t= he shares and that they have the right permissions. Samba doesn=E2=80=99t report any errors (I don=E2=80=99t know if there=E2=80= =99s a way to force Samba to report permission-denied things). It appears that the Mac acquires a load of read-only locks and so does a lot= of reads, but for some reason it appears to fail the first write. Even with= a verify, it looks like it completes the verification bit but then fails to= write to the plist file.=20 With the increased debugging, I see this in the macOS Comsole: default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_= ntcreatex failed 13 default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_= ntcreatex failed 13 default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDesc= riptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 So it looks as if it is a permission issue. Maybe the mcOS SMB client has st= arted using some bit of the protocol that Samba on FreeBSD doesn=E2=80=99t s= upport for ACLs? David > On 6 Sep 2024, at 22:48, Craig Leres wrote: >=20 > =EF=BB=BFLast year you guys helped me get this to work with samba416. I re= cently tried to upgrade to samba419 and so far I'm unsuccessful. The error i= s "The backup disk image could not be created" and I'm running 14.1. >=20 > I'm using the same port build options with 4.16 and 4.19: >=20 > FAM > PYTHON3 > QUOTAS > SYSLOG > UTMP > GSSAPI_BUILTIN > AVAHI > FRUIT >=20 > Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the o= ld backups from the zfs volume on the server before starting. I've also lear= ned the rule that you need to delete and reattach the share on the mac side w= hen you change the samba config. >=20 > Appended is the config that works with 4.16 (but not 4.19) >=20 > Craig >=20 > [global] > workgroup =3D XYZ > security =3D user > netbios name =3D red > server string =3D red.example.net > hostname lookups =3D no > server role =3D standalone server >=20 > interfaces =3D ixl0 lo0 > bind interfaces only =3D yes >=20 > load printers =3D no > show add printer wizard =3D no > time server =3D yes > use mmap =3D yes >=20 > dos charset =3D 850 > unix charset =3D UTF-8 > mangled names =3D no >=20 > #log level =3D 3 > #log file =3D /tmp/samba.log > vfs objects =3D catia fruit streams_xattr zfsacl >=20 > fruit:model =3D MacSamba > fruit:resource =3D file > fruit:metadata =3D netatalk > fruit:nfs_aces =3D yes > fruit:copyfile =3D no > fruit:aapl =3D yes > fruit:zero_file_id =3D yes >=20 > inherit permissions =3D yes >=20 >=20 > [Time Machine] > path =3D /backups/mini > read only =3D no > guest ok =3D no > writeable =3D yes > browseable =3D yes > fruit:resource =3D file > fruit:time machine =3D yes > valid users =3D backup-mini > max disk size 512G >=20 > hosts allow =3D 10.0.0.19 >=20 --Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I b= elieve this was broken by a macOS update around February. I=E2=80=99ve been t= rying to debug for a while. I=E2=80=99ve opened an Apple issue (FB14500950, f= or any Apple folks) but it shows up as few people reporting it. I posted on M= astodon and several people reported that Time Machine is broken and recommen= ded Carbon Copy Cloner as an alternative. I would like to see it fixed, but i= t probably needs some more debugging by Apple folks. 

It stopped working for me with no changes on= the server and I can reproduce the failures on two different Macs.

Things I have tried:

 - Upgrading Samba from 4.16 to 4.19
 - Upgrading FreeBSD from 13.x to 14.1
 - Setting the SMB timeout sysctls to larger values on macOS= .
 - Turning up the SMB debug sysctls on macOS to= see if there=E2=80=99s more info
 - Turning up t= he Samba logging level.
 - Verifying the backups<= /div>
 - Watching smbinfo the server.
 - Updating macOS to the latest version
&nbs= p;- Connecting to the server with Finder and checking I can access files on t= he shares and that they have the right permissions.
Samba doesn=E2=80=99t report any errors (I don=E2=80= =99t know if there=E2=80=99s a way to force Samba to report permission-denie= d things).

It appears that t= he Mac acquires a load of read-only locks and so does a lot of reads, but fo= r some reason it appears to fail the first write. Even with a verify, it loo= ks like it completes the verification bit but then fails to write to the pli= st file. 

With the inc= reased debugging, I see this in the macOS Comsole:
default 14:12:26.297714+0100 kernel smb= 2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13 default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_= ntcreatex failed 13 default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDesc= riptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action =3D= 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authoriz= ed to access TheRooT : action =3D 0x80
<= br>
So it looks as if it is a permission i= ssue. Maybe the mcOS SMB client has started using some bit of the protocol t= hat Samba on FreeBSD doesn=E2=80=99t support for ACLs?

David

On 6 Sep 2024, at 22:48, Craig Leres &l= t;leres@freebsd.org> wrote:

=EF=BB=BFLast year you guys helped me get this= to work with samba416. I recently tried to upgrade to samba419 and so far I= 'm unsuccessful. The error is "The backup disk image could not be created" a= nd I'm running 14.1.

I'm using the same por= t build options with 4.16 and 4.19:

 =   FAM
   PYTHON3
&= nbsp;  QUOTAS
   SYSLOG
=    UTMP
   GSSAPI_BUIL= TIN
   AVAHI
  &n= bsp;FRUIT

Having learned my lesson when I u= pgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on t= he server before starting. I've also learned the rule that you need to delet= e and reattach the share on the mac side when you change the samba config.

Appended is the config that works with 4.16 (= but not 4.19)

       C= raig

[global]
  =  workgroup =3D XYZ
   security =3D user=
   netbios name =3D red
&n= bsp;  server string =3D red.example.net
 &nb= sp; hostname lookups =3D no
   server r= ole =3D standalone server

  &nbs= p;interfaces =3D ixl0 lo0
   bind interfaces= only =3D yes

   load print= ers =3D no
   show add printer wizard =3D no=
   time server =3D yes
&nb= sp;  use mmap =3D yes

 &nbs= p; dos charset =3D 850
   unix charset =3D= UTF-8
   mangled names =3D no

   #log level =3D 3
&nb= sp;  #log file =3D /tmp/samba.log
  &nb= sp;vfs objects =3D catia fruit streams_xattr zfsacl
<= br>    fruit:model =3D MacSamba
 =   fruit:resource =3D file
   fruit= :metadata =3D netatalk
   fruit:nfs_aces =3D= yes
   fruit:copyfile =3D no
   fruit:aapl =3D yes
   f= ruit:zero_file_id =3D yes

  &nbs= p;inherit permissions =3D yes


[Time Machine]
   path =3D /backups/mini=
   read only =3D no
 =   guest ok =3D no
   writeable =3D= yes
   browseable =3D yes
&= nbsp;  fruit:resource =3D file
   = fruit:time machine =3D yes
   valid users =3D= backup-mini
   max disk size 512G
   hosts allow =3D 10.0.0.19<= br>
= --Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880-- From nobody Sat Sep 7 09:51:00 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 4X17dw2Zrxz5VGld for ; Sat, 07 Sep 2024 09:51:16 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4X17dr6N5Xz4WZ1 for ; Sat, 7 Sep 2024 09:51:12 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=NtOsiMrY; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id DAD5D4E670; Sat, 07 Sep 2024 19:51:00 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725702660; bh=W0Ozui+Bz62OZOoaw2a/SbrGSRU=; h=Comments:Received:From:Comments:Message-ID:Subject:References: Content-Type:To:Mime-Version:Content-Disposition:In-Reply-To:Date; b=NtOsiMrYuu5HgMncDu2qfd/+ZyiMKx//+4Qa9iMYGaqj4zZW9TJI9NDxs7+kQEaWy tzmXAyfceBEWLvCh2m64t1kU/BS+iCgvuEhaVGP3MhIwQNeVrpi1CNtD/Q2hKKyD/x onQ3ATPhuYTVn6XkNOFRmBgzcQui9uLks1ro/K60=o/K60= Comments: QMDA 0.3a Received: (qmail 24713 invoked by uid 1001); 7 Sep 2024 09:51:00 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> Content-Type: text/plain; charset=utf-8 To: freebsd-hackers@freebsd.org 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-Disposition: inline In-Reply-To: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> Date: Sat, 7 Sep 2024 09:51:00 +0000 X-Spamd-Bar: / X-Spamd-Result: default: False [0.17 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.25)[-0.254]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; RCVD_NO_TLS_LAST(0.10)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[emu.st]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4X17dr6N5Xz4WZ1 On 07Sep24, David Chisnall apparently wrote: > I believe this was broken by a macOS update around February. > > I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is > > "The backup disk image could not be created" and I'm running 14.1. I'm going to ask a silly question here. But why are people running samba instead of netatalk if they are only using the timemachine backup capability? I often had difficulting with Samba and timemachine and then I stumbled across an article on how to use netatalk - sorry, link is lost now, but I can provide configs - and I've never looked back. Timemachine backups and restores work flawlessly and have done so across a number of previous macOS versions. I have nothing against Samba, but it's kinda the swiss-army knife of network file systems with plenty of complexity, whereas netatalk seems much more specific and simpler. What am I missing? Mark. From nobody Sat Sep 7 11:02:49 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 4X19G34HdMz5VSjQ for ; Sat, 07 Sep 2024 11:04:11 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 4X19G16xdTz4fWy; Sat, 7 Sep 2024 11:04:09 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=oxAjBvnI; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 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=1725707025; 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=moWVi0bvneR2LqpFMppvgNedJeqXiuLKA51o3QNaVNc=; b=oxAjBvnIVW9OgU8dF/r3xHUAB71w++7GHcsbmvtnEHH8YHJUtvk9W6S5KrefL8Kkvm44zm B6I1sSwzNsuKXzpCgwaKO5VwQ5tZVaWsa1BG7c+5PQMYTT34MV3wx1Z6oiQQwYO1ukPrRq GfQLEsh+rjHK1wpb/aA5ACax0fh1k/PYpHf4J1VxWKmeGE3Pd9jo/nVIPXKD26ry5xrV5T V7ZeZVsSlsQU0HVN7JzO49tX7S6Sa5rnRt5Sh89oSwthzq9oLNttTXkZiDqg8u9TLc3Gmc xjtNraRXU/GdEem9vmIrxIMxk3L/81OP2dyZJH1l46hyaHqDzI8Nqn/M4exB7A== Date: Sat, 07 Sep 2024 13:02:49 +0200 From: Alexander Leidinger To: Alan Somers Cc: Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-Reply-To: References: <7d1a0ae5-b047-4b2b-894e-615af0a5093e@digitaldaemon.com> <86y1453j1k.fsf@peasant.bootbsd.com> Message-ID: <2e88429c28993e32ccd915ec9f4f884e@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_e021ac64dfc6524111fe34ed52e19b54"; micalg=pgp-sha256 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.97 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.866]; 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]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4X19G16xdTz4fWy This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_e021ac64dfc6524111fe34ed52e19b54 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-09-05 23:12, schrieb Alan Somers: > On Thu, Sep 5, 2024 at 3:08 PM Dmitry Salychev wrote: >> >> >> Jan Knepper writes: >> >> > Is this used? >> > >> > Does anyone from the team monitor this? >> > >> > https://scan.coverity.com/projects/freebsd > > I used to check it, years ago. But I gave up. The UI is too hard to > use and false alarms are both too frequent and too hard to suppress. > Plus, it's a real drag that I can't run the tool myself. Instead, I > need to wait for the next scheduled run. We have a self-hosted multi-language static analysis engine in ports, devel/sonarqube-community (I'm the maintainer), the community edition had support for C, but lost it. That required a build-wrapper. The wrapper is linux code and I haven't tried to use this linux-make-wrapper on our build system back then. The paid versions of sonarqube don't require the build wrapper and support direct analysis of C/C++ code without the wrapper, but at the place where I have access to a paid version doesn't use FreeBSD at all, so I have no justification to spend time there on FreeBSD. The cloud version also has support for direct analysis of C code instead of using a build wrapper (free for open source stuff, e.g. on github), but it seems FreeBSD is too big for my free sonarcloud (https://sonarcloud.io/project/configuration/AutoScan?id=netchild_freebsd) access (no error message, but the analysis never finishes). There's also the possibility to integrate sonarcloud with a CI system and have the code analyzed by this instead of via the automatic analysis, but I didn't take the time to check which CI system is supported and what it takes to have FreeBSD handled by it. Anyone who is interested: feel free to ask questions (DM or different thread, not here). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_e021ac64dfc6524111fe34ed52e19b54 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbcMugACgkQEg2wmwP4 2IbDtg/9FFoxhIJOtZ6KY8sQKaYJXI8GWstlBIs1VfXd52lCQvFR3+QSW5I9S9/n 74pFH/Bi3gB2RqPy4zPCxrDvY5bWTspFyZ+/z7h6vHKMeOu2QynJkP280s5vV+Hv kFdpwSrZ86xZNVoCDulBjf4tnYfRri0rxA8pduZWalgFcl3HLNyUcQkiCvF2PLDv Wai0ASN/8t49gDJ+78dom9NIL8LVi9GWeoeJ3ik08Yd+fbtQcypt18dN14H2t0fQ LRUQSiD09cqA5ucY8Op5qZDN/buW3lOXTx/BGl6vcKk4YDiBDYlAA1saa1T6kOcG REI3Okt+pjDQKSOtAJBfgjNCrZGeof9bq3useOZwiGh6wNKAuF332Tz/GjEvmp2G xwKWrsNMGlqwvnAsRFVq8FRDasH+HmfEigfkjIkEAie2QirBaZAFltvq9SEkWzRt Sr5NnUyuQD5nUJJqE6+5vkM/0f4NAr9t8GOhcojZxdWfQ5H9BrdkP16MbNOW8ls/ nAed6ptdUTWXgc995SKY6kLP6FnfLrN4/eUTJKRVknrfNa7SFZAhSPP+vdzlVwQx 35zhLRFu51hNaUI4NHDqFo2PWmvsV9ENLnwNmNDTbqU65eNuKupEA9oG/6wwGwNs RJzzaYINKuOjs7bid4tnqx18m5PEeGKAa85tMGk0Qx8AFpWcSTk= =Smbm -----END PGP SIGNATURE----- --=_e021ac64dfc6524111fe34ed52e19b54-- From nobody Sat Sep 7 11:23:11 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 4X19h92Nqmz5VVvT for ; Sat, 07 Sep 2024 11:23:21 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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 (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X19h830TJz4j36 for ; Sat, 7 Sep 2024 11:23:20 +0000 (UTC) (envelope-from ml@netfence.it) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it Received: from [10.1.2.18] (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.18.1/8.17.2) with ESMTPSA id 487BNBhI061636 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 7 Sep 2024 13:23:11 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be [10.1.2.18] Message-ID: Date: Sat, 7 Sep 2024 13:23:11 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> From: Andrea Venturoli In-Reply-To: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.26 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.53)[0.532]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4X19h830TJz4j36 On 9/7/24 11:51, Mark Delany wrote: > I'm going to ask a silly question here. But why are people running samba instead of > netatalk if they are only using the timemachine backup capability? A couple of possibilities: _ they already have Samba and don't feel like installing something extra when the former is supposed to work; _ if I understand correctly AFPS is deprecated by Apple, which suggests SMB instead. bye av. P.S. I don't use Samba directly for TM, although I have a customer taking TM backups to a NAS, which almost surely runs Samba. From nobody Sat Sep 7 12:18:55 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 4X1BwX0Sprz5V8hT for ; Sat, 07 Sep 2024 12:19:08 +0000 (UTC) (envelope-from theraven@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 4X1BwW75Vcz4plh; Sat, 7 Sep 2024 12:19:07 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725711548; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VQa4M4nj6El7LhZ3oUm3ATNDu67LaqsNeCYtr3GjgXc=; b=S1ivcIuI7O1C9o6RVvx5OTqsBmsJZguDXb5R1NX3mDZd0flgNLFL6gx84INJ2ujJwOQj6v vWRHanwq72iK8SE6j0+qrChRvKqsFhh0lfx3x81j3mh1yVWPIPV8/+lONsIr4FtJjAhyVR cNu9OYM+h9JOxIQyS1YXINcBwJhnRI4YyHdWJWHM9lJXP8dvqOUT7+0izFuJCIHsRWz9c6 EZINRGwl/YcYcYP4YC40+iACdTK08N0Dj/OcNUKZhIbeElqmq7X3QSTvaAOr+cLN5u7mjw R0HZ0KG1gSREJl8JBkb5Sup38oMXYHnkAoS7TcI9CMQ8jvvaP2yEWSdCoXeT5Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725711548; a=rsa-sha256; cv=none; b=SpduPBiEymzIae6kEcvx4NLkIuqG/EJ2qncY+wGKRzcdILq7IIPff67Vp8Tu+QOuJ+pOw7 dXFnYuRcfVPpHUmvsWy7pad2v0a5LMWGi1/gPOu0VXPcWZfyP/JVZojQ+fAEWZm0gPgloN 8s9W1BANjF5RQ6Qrh1N01ockNuwdl6cQBwWCj0fxYTuSx8iipAlwC2ii32bQexTe3NYOpp 39AlkGhiW5UY52RVYWBu4ZXWOHpmenJcAuGisccwtTROxZUXf3qunA3e0bckr0BJQuObqg kpCHU6fySd+iX9D6hRFMmwVGCNFmoijAqICGnAaK0kBgWL/nL1jZyQi+wg8kXw== 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=1725711548; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VQa4M4nj6El7LhZ3oUm3ATNDu67LaqsNeCYtr3GjgXc=; b=qt3lHocvCmPW14137UGzAlMyt4Bh095ZuJJCPmquoxYahNMpPp6ZEFcwfeu0c9vgdQVkCq kJP12p6Zr0Qq+MPsF9x27HbQGOG0FVPA7Icta7e+4m4tUG4zfJLjRx6RzQGLcE9uxcahTi cUqcWA/X+RNKso6xsIUg+rQv+ZB8YHB7XYK1zKZovyfk+2f9bHwqcPlrtlODlVysgxdchR EWykNINvVXm+RYddX2KXcrXpx65ZvmaPohW64m2QKOI6ayU7rR310tGy6ThfHAEU9DuTgh gds3cyTFQKgNelVTecZ+yUUD+fhVY9nKH466HiTcs0x6DNlzMw/avSNr8cYPXA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1BwW6YNDz18M4; Sat, 7 Sep 2024 12:19:07 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 2B8C26534; Sat, 07 Sep 2024 13:19:07 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sat, 7 Sep 2024 13:18:55 +0100 Message-Id: References: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> Cc: freebsd-hackers@freebsd.org In-Reply-To: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> To: Mark Delany X-Mailer: iPad Mail (21G93) On 7 Sep 2024, at 10:51, Mark Delany wrote: >=20 > I'm going to ask a silly question here. But why are people running samba i= nstead of > netatalk if they are only using the timemachine backup capability? Does AFP still work with newer versions of macOS? I thought they removed sup= port for it with APFS. David From nobody Sat Sep 7 17:49:10 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 4X1LFb0NMlz5WBYL for ; Sat, 07 Sep 2024 17:49:23 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4X1LFX0V82z4XgN for ; Sat, 7 Sep 2024 17:49:19 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=gZjx0x82; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id 711BA4E670; Sun, 08 Sep 2024 03:49:10 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725731350; bh=4hUATgWU2kYMNaT7hRaeV6flNBg=; h=Comments:Received:From:Comments:Message-ID:Date:To:Content-Type: In-Reply-To:Content-Disposition:Subject:References:Mime-Version; b=gZjx0x82QDFTdC8VT88YIDPVGGvk8kqxIpxNrHPCAxa/fX8kRuo4qpoch8kNEFrBX tQhEd3mRrrhuvPcLfKwpFVrswc//ZW4+D+0lN5ND0hhhxo9q69HFx7iEbAT+reik83 rGmoDjg0tYdOiH0osZeFuakF1EfvXjBJprbCDv+Y=CDv+Y= Comments: QMDA 0.3a Received: (qmail 28260 invoked by uid 1001); 7 Sep 2024 17:49:10 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725731350.405-0x98b0ab@qmda.emu.st> Date: Sat, 7 Sep 2024 17:49:10 +0000 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=utf-8 In-Reply-To: Content-Disposition: inline Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? References: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> 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 X-Spamd-Bar: / X-Spamd-Result: default: False [0.23 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; NEURAL_HAM_LONG(-0.19)[-0.186]; RCVD_NO_TLS_LAST(0.10)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[emu.st]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4X1LFX0V82z4XgN On 07Sep24, David Chisnall apparently wrote: > On 7 Sep 2024, at 10:51, Mark Delany wrote: > > > > I'm going to ask a silly question here. But why are people running samba instead of > > netatalk if they are only using the timemachine backup capability? > > Does AFP still work with newer versions of macOS? I'm doing timemachine backups from Sonoma 14.6.1 to afp. It would be a pity if they did remove that support. FWIW. My rc.conf <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< avahi_daemon_enable="YES" netatalk_enable="YES" # conf=/usr/local/etc/afp.conf dbus_enable="YES" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and afp.conf <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< [Global] afp listen = 10.1.0.4 fd2d:e363:95de:fe:10:1:0:4 hostname = HomeServer guest account = nobody [dog] path = /backups/timemachine/dog time machine = yes vol size limit = 1000000 valid users = dogafp [cat] path = /backups/timemachine/cat time machine = yes vol size limit = 1000000 valid users = catafp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With dogafp and catafp set in /etc/passwd Mark. From nobody Sat Sep 7 18:18:44 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 4X1LvX4zpfz5WFn2 for ; Sat, 07 Sep 2024 18:18:48 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X1LvX2c7rz4cQP; Sat, 7 Sep 2024 18:18:48 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725733128; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=U6lac51ePsoTgdARPGCH8F7wqU1VBBVtjIDTWAxX1X0=; b=aJV5KVdhx0SeWLFTBdlay1UVNuUDHOdbPRUU8QlXOxEUX5DSY4CShyoDGEDSufugL4WHMY VwRlVnRWy4eZl6u22D9spBNSwC6atKAocaLyxMN3AMmRTddvCqCnDeCl5XD2Csj7yf2PAa F07kIUUWFaMYAtbq+Ige/jNn6LL0WNKvK2cSj8TtL7lNWE2Q2z8ZL2gLwAoVbepdnnQSno 8kRQDrbhGNLMQK8SSc9Wk/ozl5281su3TT5shAVSX3GBaLPrA/lzXEuasvrUwfCqylCdqn qY7Kpqz7GAwksbjyPvNn6UYgpnUMgl8eDX566rbWdLjzRVlD0PRhGm0VZto2dw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725733128; a=rsa-sha256; cv=none; b=UTdE9biRzarYfEqErY+vSpY5DtLCY1nvZTtmhXv3yYUg5r1XzwJiU9tcIitumISe1xaSAr ZYElexNja2j66f43ZZqIWhpbGvUj2MM2ATb8elOwOsWGj/octc+DUAnfkWomKT6QsT0mif SZzvf6r3/jTfS6/5IjpSlSSDnb2oELI4jGYW+mSDnqVdkd783IJbmuA8QewL9ejMGbxq1F NBqDbVBAPt8Lc5CmlQD2V+Hk9dvUEDbvq8EevUaLx7YcGyghk+Ugxunr7JzzmjiVzRArQG ObKhzBGLm5jxAODxTerGt/VqtC2c+4wcavcZotVGIRgZvcqhj65vyhEMDUUlEg== 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=1725733128; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=U6lac51ePsoTgdARPGCH8F7wqU1VBBVtjIDTWAxX1X0=; b=BGt5lg7d4xLcMZWmCd9YsWcJnWUBGVZeMUIeJEFhehQOhGxybc2ayIKFNYASt1VIiBMMkt oCZzN8NNyNIgp04sSMuyC/hxU1qdvpfDRvFqjSYNGllm6IlC6WgFLWc1/ApTO8PerAVSN5 qiU6GpEkBiDTkIZBUAOkL7DPCZy8TsGfrVPyBj7J7Mh04BwlQVjyh2w2+MTW2GpuSK0K4J ekXHZVpg77mzQ/JKEZTaT1YjsRJvB/5pY9wELCYkY3M+2/3i8s9ir4mB697HmTI/VdM6GJ UeQSDX0equ9s5+LJCmpb6cTvKTVfk9Rg3/x80RuwVVF+t8KR5L5Cnm/NI+UFlg== Received: from [192.168.119.159] (p5dc83c4d.dip0.t-ipconnect.de [93.200.60.77]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1LvW2Wpzz1GXJ; Sat, 7 Sep 2024 18:18:47 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> Date: Sat, 7 Sep 2024 20:18:44 +0200 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 User-Agent: Mozilla Thunderbird From: Stefan Esser Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? To: freebsd-hackers@freebsd.org References: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> Content-Language: de-DE, en-US Autocrypt: addr=se@FreeBSD.org; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNJ1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPsLAlAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9B BQkTLNNOAAoJEEfrte9a/fVEV1oH/jt+SjRqTHci6d1LiFDfbY0E2rfobZw5BhcQuCqxahS7 pcE1oLpUaoqWYPHslxhGTl7QSD2twMWcHLonZ1lgTJluMZqgTX9uvqEYDUtiH6G+IF7Qacat eUsAvwdycItPOr3p7WBt8U54GbnQdxpSUQ0OpD4twy7KAt/MPNLofVQSEea5DNQOH2dXILrf iRsNfFPsfTASOUXOTRyTYwm6Ys76LIdL9GA2iR5qw8G43FB02fiX76WQSjg+yKN9iP9racGg Pc8qkSPwHJr0s3OwJC4ndbCuSiaXddDbgOvdrqfSO0XCjo3ylyEBhmMVMpwkj8pLCKVGS73n Ncs6OujZXAzOwE0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAcLAhgQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJmvl9BBQkT LNNOABQJEEfrte9a/fVECRBH67XvWv31RCrvCACY7fjahcGj/57peFu0oIb4X9X78H6mgrAZ D5HCCCb2vWdNtSDTYQoYnKP2Fz9RUG8ETT9a6CtymYqQc72/dzjJmakRTlbYhliKJDZXGAYU g34VirGXCjYgWH7l+0CupOtt55R/ASnrnXX9R/7PLO+akObn9Cz/bNBnIbYnTjLNs7GMMQL4 uNSyqIByQ3LVsVDaCq3408fYKC0dtlv2VNQQzcXXwOgecwpS2UeqMflrSA7UfPh15WgkpnrN AnKCtS66eU1w2kTCsVEjGQEgLI5pP1HMNRHjnHncAFSpOfs1EZn0MfhiyB+4T+lrccGI8EZu ay791Tx4QdDKkdZGaV9A In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 07.09.24 um 14:18 schrieb David Chisnall: > On 7 Sep 2024, at 10:51, Mark Delany wrote: >> >> I'm going to ask a silly question here. But why are people running samba instead of >> netatalk if they are only using the timemachine backup capability? > > Does AFP still work with newer versions of macOS? I thought they removed support for it with APFS. I have both Samba and NetATalk installed and running on my home-server. Timemachine baclkups are working well using samba-3.16, but fail with samba-3.19 (corrupting the backup!). I have used netatalk for timemachine backups, do not remember why I went back to using samba. Maybe I should try using netatalk again, since then I could update samba to 3.19 for other file systems. BTW: vscode on the MacBook does not work well on directories exported using netatalk. Every "file safe" operation warns that the target file had been modified and asks for confirmation to overwrite it. I have not tried to diagnose this issue, since it works well when using samba to access these directories. Best regards, STefan From nobody Sat Sep 7 19:11:45 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 4X1N4j0nWtz5WMQk for ; Sat, 07 Sep 2024 19:11:49 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1N4h3SwZz4kcW for ; Sat, 7 Sep 2024 19:11:48 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=alxmlxTB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-42c7bc97423so33770025e9.0 for ; Sat, 07 Sep 2024 12:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725736307; x=1726341107; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=xP8mApGyJNXoz+d22/x7e74AaoYDILB7O6UvON02HmU=; b=alxmlxTB7Dv8N5EuvhPLrIhls95H+uxsSoNidRhzmMjCrpWE85m8228/fDTBFYMcVY xI23pswBqGaMgFnXgUc5HKQ6Qfc2HQqVJolmSvro0Pz3ME/aAGSb/81OV5kWpgaB8BQH xiwxILHsqmd7fe9hh268VgLp1cN9soO98o9GaxMkIaSkEQGyM39WZrSQXwIJzs8aQBUA N9rs0RL96A3XNYl7mI7ZR+Ilj4gdwLLOnyuVetmcCBOkRUYc4dbDdQPTSAP9CCXVeKi3 azAvPFZf7EA37Ge5wr2yeaaUgP0lg8fK5o/AnxIzFMp3kTjdIa6Hzw/0iKwD3mJHs6WP cTRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725736307; x=1726341107; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xP8mApGyJNXoz+d22/x7e74AaoYDILB7O6UvON02HmU=; b=pLq5C/H9gDBdnEDAZxlFrCR4zis5cY1d7R2TtuH8AWaNwu+AEX45RdIaDmxi6PbAXT NREZiE+vf462rtfKPnwUfSp38R/0UrgtBxJqhoOuwLCSvIKGdy5NDvGiwOcEB5aRcdpF FEBM4QcUukF1395MeltohNasj07Z9keDyIBX/9kAOb5vPRu8VYtH4j4+KW1K8Woe72Q5 uyw2vzyPP5w2RVuq0h8FHGPe+wIQBs+B5oJOU6dN30mlWaULx4odoSvBTnwjrTJ/PnMy dxatSzSrE5yhV7GZcGI86RH9oARKLnrGxXuAyNy1s3WdvglE9zpcIJmgbxeGnq++5Qzy 0Utg== X-Gm-Message-State: AOJu0YyWCunTleVfBavS+StD4oX6hLvQESooP2opPwtfhJZdiZOslxKP 7DqiwbExweC5btlOndtVAkXU8JzKiIBwY2liNfpmSvQUMv493Bc5rHtLcw== X-Google-Smtp-Source: AGHT+IHXlBY4BFcYhpbkOQOqOZpJd9/v5XMiW3FmU5FblckVUMvUgIm9j2dYIGe95DXyNRJh9+1Dhg== X-Received: by 2002:a05:600c:1d9f:b0:42c:b220:4769 with SMTP id 5b1f17b1804b1-42cb2204a93mr5605005e9.32.1725736306609; Sat, 07 Sep 2024 12:11:46 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ca05c2845sm55448845e9.3.2024.09.07.12.11.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Sep 2024 12:11:46 -0700 (PDT) Message-ID: <65faacbe-f165-4ed7-a018-d7ec1913a13f@gmail.com> Date: Sat, 7 Sep 2024 19:11:45 +0000 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from] X-Rspamd-Queue-Id: 4X1N4h3SwZz4kcW On 05-09-24 18:09, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. There is an analogy to be made with the motor industry. A lot of drivers (and the motor industry) resist any new safety regulations. We don't need seat belts! Speed limits are only for unskilled drivers! Manufacturers were against seat belts lest it harm sales by making people think cars are dangerous. Drivers felt them unnecessary because of their overconfidence. It's not just legislation that have improved matters. Individuals and non-profit organizations have also had a big effect. Ralph Nader's "Unsafe at any Speed" and Euro NCAP have radically improved automobile safety for the better. I think of C as being the Austin Metro of computer languages. When the Euro NCAP ratings first came out the Metro got a one star rating - the lowest of any car at the time. Sales cratered and the car was soon withdrawn from the market. There have already been several posts saying that we don't need nappies. We don't need seatbelts or airbags or ABS or any of the other safety features either? If the EU and US do regulate then it may be the thin edge of the wedge. The Euro NCAP tests have evolved to become tougher as time goes by. Legislation continues to improve. Even motorsport where speed is of the essence is heavily regulated. In Formula 1 the number of fatalities has dropped from over 1 a year in the 1950s and 1960s to less than one per decade in the 2000s and 2010s. Finally, I don't think that denial is in any way an answer. There's not going to be any silver bullet. I do think that C is unfit for purpose and should be replaced. I'm much more of a C++ expert than any other language (specifically in this thread Rust). C++'s unfortunate lack of a well defined ABI makes it difficult to use for kernel development. I do recommend it for userland though. In the past the BSDs blazed the trail with the development of UNIX features. In the future is FreeBSD going to be stuck in the C mud whilst the rest of the world moves on? A+ Paul From nobody Sat Sep 7 19:20:32 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 4X1NGr2tcMz5WNkP for ; Sat, 07 Sep 2024 19:20:36 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1NGq2zCYz4mHb for ; Sat, 7 Sep 2024 19:20:35 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=PT1WPHbv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::333 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-42cb2191107so1178225e9.1 for ; Sat, 07 Sep 2024 12:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725736834; x=1726341634; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=6zByH2onN+x5hKJldswyZE2WtIJ/l1M9AAhYKZ8Ebhs=; b=PT1WPHbv9jdgAa27VRYsDFqQRcLcTZ4ezzBBHLtOzXIvij9TGVQSK7oc5N0BOPXRX/ CABKtIlwEL1JdrDVxNrsNQmydMHmPQBZ9S0RojAF3fNXkm3pdxSkAY0IKupkbkWjebNV 2qCQJd+N+gwLXGKeysONBNODQRvCxTd6AR+/ZmruMSIS2RnPT0CyxB1G9O+wpE8WYR2H AZuaUPLrj8pDFFKHAFIYSo3eB1whLlWN8/UR7ETzBUKH2bm2RkT+3+K3r3z6E9TbmjmB mWy5Nz9XtCIBnbbTVf4IQ88ms09BkFH+YEsdedcwpPMrQXotkMU+QRJWM9Ri3jJ6EPVi JMGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725736834; x=1726341634; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6zByH2onN+x5hKJldswyZE2WtIJ/l1M9AAhYKZ8Ebhs=; b=l4lee5bjx1ZfE3nHZ5JXO1LtBKVVZYTKsxwYsaEzwtjovuD8sbsbqA0UruLlt0Ignu 1hsnlzsrSYmSy2RAW8oYIIgx5GLSwNamMauko5vd9cJJGbV//Q8yhH+4o/Vd0LMMd8fs aGTd4oUKTskzknMG5H88OK2/8DVYh5aFIwIDLE65f7QQtLIrG2P07+rPCYno2JAmnnS1 KIZchwtfyaISHASzTLqyQLlTLzjmrBxQGOSdyIO2EFwxoCADOJjo7JlNkvHOMpGiT+7K +rZ3hM2YkhjB26JxIyA2k8VJODQTB/EiHo8CopTMnM5GmUzemyQ9HrUSD8JpchRB1IMd X/Mw== X-Gm-Message-State: AOJu0Yz2+0EnXLCDDWIX5cbBsfyrFsJU8leYMXoMum+nDx7661gTTPoG jjUhYPU4XuVrfH/klEqCXaoZmD+c+SA5OS0elculz/nmgPzrd7ccXP1pZA== X-Google-Smtp-Source: AGHT+IHlalQDhL9XuH1+15fOAvLjQ8PdhaluJOK5LeodUO1pv134cj9T0aGHQqW0V4378td1BzJNuQ== X-Received: by 2002:a05:600c:4e4e:b0:42c:a580:71cf with SMTP id 5b1f17b1804b1-42cad87eed8mr21953405e9.30.1725736833555; Sat, 07 Sep 2024 12:20:33 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42caeb43d73sm24225405e9.24.2024.09.07.12.20.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Sep 2024 12:20:33 -0700 (PDT) Message-ID: <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.com> Date: Sat, 7 Sep 2024 19:20:32 +0000 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> Content-Language: en-US From: Paul Floyd In-Reply-To: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::333:from] X-Rspamd-Queue-Id: 4X1NGq2zCYz4mHb On 06-09-24 07:41, David Chisnall wrote: > On 6 Sep 2024, at 08:25, Poul-Henning Kamp wrote: >> >> I will also note that almost all the blame for C's current status >> lies with the standardization efforts, which almost seem hell-bent >> on destroying the language rather than improving it. > > As someone who is involved with C++ standardisation and so periodically hears things from WG14, my impression is that the people who care about the things that you list have all moved to C++, where they were solved problems at least a decade ago. The people still actively driving C are the people who didn’t leave because they don’t want these things (and, increasingly, C++ people who just want to make sure that C doesn’t diverge too much from being a subset of C++). +1. SG23. There is one prominent case of someone moving from C++ to C standardization to get a proposal that was rejected in C++ adopted in C. I have seen some papers with proposals to improve C's memory safety but I doubt that they will ever get off the ground. C++ code that follows the core guidelines is already very substantially more secure than C. SG23 is working on improvements. > It’s trivial to write a packed struct in C++ where the fields are all BigEndian that do byte swapping on implicit conversion to and from T, for example. Integer ranges can be implemented in the same way and there is a proposal to add them to the standard library that looks nice (the ranged integers are a small part, the proposal is mostly about units and quantities). > > Having written a kernel in C++ Out of curiosity, did that mean limiting the ABI use (no RTTI or exceptions). Did it also allow using different compilers (say clang and GCC)? > and worked on two in C, and read a reasonable amount of one written in Rust, I am firmly of the opinion that C is absolutely the worst choice for writing a kernel. This was not true in the ‘80s and it wasn’t true even 15-20 years ago, so the question is how to move from where we are to where we should be. The strategy document that I coauthored at Microsoft recommended the following: > > - C++ conforming to the Core Guidelines and with static analysis for existing C/C++ projects with the C parts incrementally migrated to C++. > - Rust, C#, or TypeScript for new projects and discrete new components with well-defined interface boundaries. > - No new C code, except in open-source projects that accept only C contributions. Sounds like good suggestions to me. A+ Paul From nobody Sat Sep 7 19:31:13 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 4X1NW86C0zz5WQ3f for ; Sat, 07 Sep 2024 19:31:16 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1NW80Ft4z4p1P for ; Sat, 7 Sep 2024 19:31:16 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=gXlzyoXV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::434 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-374c7e64b60so1721851f8f.2 for ; Sat, 07 Sep 2024 12:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725737475; x=1726342275; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=LrIU87hIrcF1dQasemssL/C+lwR58eL48lRq+R0m2fo=; b=gXlzyoXV4MesyWB/0m2dean+DgrkoVlMmNs0GXx4tUYhcZ2qUsZthO7YA2+Hc6PUvu +8ejkhhjvTSVnbTFd5jNcgQopdmpxeEt7UIBbarrOpN9YsvbWRJqwVEcDDfo502I51Kp U/O6INYUaM4mNz9Qu5V+GAtmFgtRUAp7tG9sud0pbDRvL82xg8x7NiYt5irUZBlkBavM /Nivi7jpBDPOx0wQVIkHjhPwyAY3EXCZWRmym7TwNivIhJSwdsETYk2jb1VSLO6tv23+ tLUMxp9H+pPhEfLsHKpbzIO9OMxH3tFXFA7qdRwLXSzrP+eZAe4MSSeQTMKCNskbj5bU /GhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725737475; x=1726342275; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LrIU87hIrcF1dQasemssL/C+lwR58eL48lRq+R0m2fo=; b=XvF7GbgBgNmZvl7T8U6ie2zqd15+HvrgdVd4QP+6stGsechZ5C0hctO52bE5EpRo65 fWsa7Z8PCYFCMieBXgs8DVsnkXKyFE9ucIbcDS208Y9C4P93IqpDnRbL8GX/y8GqKSJa 7OxKw67ih7+I9L0u/IA+pq3Z+CMyJ4dlqf8NVl2cwCPnNpoOuQmoDenlb+hhVrniT8An oW+4jHnSExLDafKFckZR/KhUJEu+n3J9SIE5aE0WnPP7IUdmUxegWWGvF+7N6hJ00Ijs o4yssIvNuXW/eX95rsX+sWmjIOqffPaKIGNQlh4+FFXSMavGOG8mk0QDWcu6V71h6xiP kiPw== X-Gm-Message-State: AOJu0Yy934KVHKBaNUwaQ4Uc4ZgEk1xwIExCtA0OW38TwR3fJTSwEq37 gBnCijxYBBfjoIypBoRXICTi4jxyXeAJnLuvB/FTdC1V4y8MJqskIgJ0Iw== X-Google-Smtp-Source: AGHT+IEwTRfu8JBtUp74Vc5CblA9HXftAxZva6kqQQE2rRbC8WgVp75CC/6oGW4kjl1O51OEVqLd1g== X-Received: by 2002:a5d:62c3:0:b0:374:c407:4e07 with SMTP id ffacd0b85a97d-378896a5b83mr4404061f8f.46.1725737474511; Sat, 07 Sep 2024 12:31:14 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-378956ddbbbsm1925153f8f.93.2024.09.07.12.31.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Sep 2024 12:31:14 -0700 (PDT) Message-ID: Date: Sat, 7 Sep 2024 19:31:13 +0000 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::434:from] X-Rspamd-Queue-Id: 4X1NW80Ft4z4p1P On 06-09-24 21:46, Brooks Davis wrote: > While bugs you can't write because the language doesn't let you are the > best bugs, we should also be looking at deterministic ways to improve > our C and C++ memory safety. In my biased opinion, our most realistic > option for making major advances here is the adoption of CHERI[2]. > We've got Arm's Morello prototype today and we expect commercially > available RISC-V silicon in the next year or so. At this point I hope > to merge CHERI support from CheriBSD[3] in time for FreeBSD 16 (subject to > standardization timelines, funding, and hardware availability). In the > meantime, we should be looking at orthoginal techniques such as enabling > default initialization of stack allocations. CHERI does indeed look interesting. Another thumbs up there for David Chisnall, I really hope that his endeavours take off. ARM's MTE uses similar techniques (though less pervasive and less secure as I understand it). JF Bastien published a paper based on default initialization https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p2723r0.html I think that is a great idea. A+ Paul From nobody Sat Sep 7 22:16:41 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 4X1SBH3Knjz5TqQ2 for ; Sat, 07 Sep 2024 22:16:55 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Received: from f3.bushwire.net (f3.bushwire.net [IPv6:2403:580c:e522:0:203:0:120:11]) by mx1.freebsd.org (Postfix) with ESMTP id 4X1SBC3cFlz49xJ for ; Sat, 7 Sep 2024 22:16:50 +0000 (UTC) (envelope-from x9k@charlie.emu.st) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=emu.st header.s=2019 header.b=Kp+FUUHK; dmarc=none; spf=pass (mx1.freebsd.org: domain of x9k@charlie.emu.st designates 2403:580c:e522:0:203:0:120:11 as permitted sender) smtp.mailfrom=x9k@charlie.emu.st Received: by f3.bushwire.net (Postfix, from userid 1001) id 4AF234E670; Sun, 08 Sep 2024 08:16:41 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1725747401; bh=8Sn7b8CkmKmLZXauggQkD7dg0bg=; h=Comments:Received:From:Comments:Message-ID:Date:Content-Type: Content-Disposition:In-Reply-To:Subject:References:Mime-Version: To; b=Kp+FUUHKqb1bpYrgzgwFdR+rA9n8gn4T2YUcueCtzI2aKbX2TiBdQaXbo7A2LuPBY ucCkitNY4L9YWfyK7cFOcX2uoXzXWe4TvFICIW7I3fNlkJTouUeo+BICabVy/rI4hD Ae3f7BPmcfEg2kLxyp/w6WTxviPLqPCHlG94y/qU=94y/qU= Comments: QMDA 0.3a Received: (qmail 30021 invoked by uid 1001); 7 Sep 2024 22:16:41 -0000 From: "Mark Delany" Comments: QMDASubmit submit() 0.2.0-final Message-ID: <0.2.0-final-1725747401.247-0x0f62fa@qmda.emu.st> Date: Sat, 7 Sep 2024 22:16:41 +0000 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? References: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> 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 To: freebsd-hackers@freebsd.org X-Spamd-Bar: / X-Spamd-Result: default: False [0.11 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_REJECT(1.00)[emu.st:s=2019]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.31)[-0.310]; R_SPF_ALLOW(-0.20)[+ip6:2403:580c:e522::0/48]; RCVD_NO_TLS_LAST(0.10)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[emu.st]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[emu.st:-] X-Rspamd-Queue-Id: 4X1SBC3cFlz49xJ On 07Sep24, Stefan Esser apparently wrote: > Am 07.09.24 um 14:18 schrieb David Chisnall: > > Does AFP still work with newer versions of macOS? I thought they removed support for it with APFS. > > I have both Samba and NetATalk installed and running on my home-server. > BTW: vscode on the MacBook does not work well on directories > exported using netatalk. Every "file safe" operation warns that the > target file had been modified and asks for confirmation to overwrite > it. Indeed. Just so it's clear, I was only addressing the question on the subject line. That of providing just a TM service. As Stefan points out, Samba is likely to be a better choice if additional file system services are required. One presumes that if TM doesn't work with current Samba it should be possible to run both Samba and netatalk together, but I have not tried this. Mark. From nobody Sun Sep 8 07:44:16 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 4X1hn01NCcz5WGTX for ; Sun, 08 Sep 2024 07:44:20 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X1hn00Tjvz4Nr1; Sun, 8 Sep 2024 07:44:20 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725781460; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6cX3f/NFWhEm+d1CTUtU6H8uV6yrb1+yR7L4RR4HBiM=; b=nYnW8P5MBUhx5hvnZGCvj9Njrry/xCnMp/UCtW6I+WQKc55ckHBLOERSwUpYEWx6+EEiCz 6bfbJL5/25DqJBG1rtVk3fGpmq73LI95d3wtSf3FAySN5LP4rEioQt9zTyYZivJDw15kI9 lGkdQ+CXRBI+tqwihdj1npNvK0hzLx/HGogwv3rFVDT+h2mQ9BRGUurnBd1V7YU7NQJ07s kbJT5Dzf9H5d5lkVikzM74s28q6OCQJhJnAdkhIjQKR5IknEhxVWMQmJIJISaZbZETfSwU eBTDJf4MLcWHAEeEwHDv6uX379up8plkDQqFmoAs/QtqNbhYTsnIY2roOMkcSw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725781460; a=rsa-sha256; cv=none; b=EtOEBVBvy14FyEwrWBeaP7YW7NhxfjRYynUpQUwZc/JbhDzF//5G3OE6oI1s7Wb6OnHxA7 SFjAs9mTQT1uY1WUJKZ9hoSzQORJv6rFNqGDszsASHs80+m4nNApMB4loGwRJAARqDvnm1 Vd1NyC2DOEmrOCMvXxeB4DpQ0mQ+GFTksSkOhPoFn6cYdHrfuv1UokzHFNgQGxMUJ9j4NT 1J70Ev7QZnzNhUI/1WxGLo9qBgX3q6Ldp8KxGtWmYiXYc0aWsA++WDh+MdSRZa3jOAcuAb M+Av2zqIpazKJthJZ5Uo/9oemQ12XZujgai0QSnmmjChNjBy/IHZdRw7wW00jw== 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=1725781460; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6cX3f/NFWhEm+d1CTUtU6H8uV6yrb1+yR7L4RR4HBiM=; b=GghWnXG/2M9y71xNkS4vV0m60qUvjE1B9Nham7UHFRAljaaIAGpT1XzR4Y/G/dULatQZZ8 erjYxKbe4+WmywJKQWU6pTztVq3ZES1WYR6ndv7hJTJmB+1TR6CS4u3Q9gENfRGgU0sScg XMxNUDPUfp6Dsr8sGxT/zv1S14UaPXlZb7Ovy/OEgVP/MelVP8sOb/dQgKw3ZZvFng5GpV jzugnNYhjKql1umPW7IbbPJ4Q7xyr++ssUTmzWO/bZ6Den88Mw7AsikmvSMCMu0NNUlgv2 aJFb/whrCNDb6rSzcabK0VxdU/sJ0q/78bg6LDx+LTYMUvTnGnearEBOtm4how== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1hmz6SXzzJhH; Sun, 8 Sep 2024 07:44:19 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id E656445555; Sun, 08 Sep 2024 09:44:17 +0200 (CEST) From: Kristof Provost To: David Chisnall Cc: Poul-Henning Kamp , Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Sun, 08 Sep 2024 09:44:16 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> 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/alternative; boundary="=_MailMate_E5759273-0E93-4EE1-AC01-902E3AC4744A_=" Content-Transfer-Encoding: 8bit --=_MailMate_E5759273-0E93-4EE1-AC01-902E3AC4744A_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6 Sep 2024, at 9:41, David Chisnall wrote: > The strategy document that I coauthored at Microsoft recommended the > following: > > - C++ conforming to the Core Guidelines and with static analysis for > existing C/C++ projects with the C parts incrementally migrated to > C++. While I’d be interested in seeing Rust demonstrated there are clearly still some practical issues to work out before we can, even in user space. So, at the risk of derailing the Rust conversation, I want to ask about C++. We already ship user space C++ code, what’s stopping us from doing so for kernel code? If we can get some of the benefit of a more modern language with much less effort would that be a worthwhile step? RAII would not *always* make reasoning about locks easier, but it would in at least 95% of cases. What would we need to do to be able to use C++ in the kernel? Best regards, Kristof --=_MailMate_E5759273-0E93-4EE1-AC01-902E3AC4744A_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 6 Sep 2024, at 9:41, David Chisnall wrote:

The strategy document that I coauth= ored at Microsoft recommended the following:

- C++ conforming to the Core Guidelines and with static = analysis for existing C/C++ projects with the C parts incrementally migra= ted to C++.

While I=E2=80=99d be interested in seeing Rust demonstrat= ed there are clearly still some practical issues to work out before we ca= n, even in user space.

So, at the risk of derailing the Rust conversation, I wan= t to ask about C++.

We already ship user space C++ code, what=E2=80=99s stopp= ing us from doing so for kernel code?
If we can get some of the benefit of a more modern language with much les= s effort would that be a worthwhile step? RAII would not always = make reasoning about locks easier, but it would in at least 95% of cases.=

What would we need to do to be able to use C++ in the ker= nel?

Best regards,
Kristof

--=_MailMate_E5759273-0E93-4EE1-AC01-902E3AC4744A_=-- From nobody Sun Sep 8 08:30:45 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 4X1jpp3Nrmz5WN0t for ; Sun, 08 Sep 2024 08:30:58 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X1jpp1Wkwz4Vb2; Sun, 8 Sep 2024 08:30:58 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725784258; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LJ1UZ2O7H3wc84AXLOLMZHohJBdmQGVRs9xGxj2SuGM=; b=aN5pVSdl1nuhDFXLY9mPtXiTo2q6RSPfXTMJ6pYtPlzcsoXb3RANOPD4n+4ZNO+IcRp1Wt 4Y98xvrP9/w3JtlKvOV3uhBN8St9gp9W9azoUIFZIji0nww9rbyd8WoTNQfRmvm6BaY/7s S5R++e0q5PeWfheOotfUUeKsD9VXm0ph4W2p0VAGciVpTvSr6lxxjMEv+CjpHT5Z98p64i /hpLdJNrmW7U/5F+uqWs55//Ku2OPnadyfWn6UThsIl1KzGDaYeU+PMJPKH1UTRycD3Thg 7sDDyluU7VdvAieTrBqW6KLEbEstrYP4Rkzd2qMoLROO803+Cyb5tstxJz5Plg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725784258; a=rsa-sha256; cv=none; b=oVvi3D2u9Z1yEX0RMMExgH1Bry1DVZmyDwfcqtme7Q64ZNtWqsLdimXzDgR+jgfyXv3uBy AR2Z8RNCtCwjkg1HnE3c58sgdpO9Hk3L8ZpaoJCq5yoyfuwLpmlC4q1x0vWgGdGD4jq6va n/JxLnYRlqSmTjRMKEEZXi7B+bakdLdeaPO1Rpaohsn+1NEe2hiPCUCGB0SxsZVdWXbX1j BB5/Zf0JfQoW8Zm8t/lBACpyQclwAFleaV7oFM/HRz04SxGhkkdHDQB/rN96A8ZJ8QdK5c tgkgptGzT4Zd8avbKhM2Kp9tlUeNVnICC3xJ701DWuGnaa8oqj8B4jyxDl9mUw== 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=1725784258; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LJ1UZ2O7H3wc84AXLOLMZHohJBdmQGVRs9xGxj2SuGM=; b=qquP6u9k4Caizkj5XWMCxEiofrYRFdKB1L/QUfbqU/X8IipVJ0ixQHhXRsBqi3ZhmUEHWd awue2SR7LlwORefhX+wlNThX7VzOy/aI2dXqIxbqxXGyzyJEo8/aaHWb0FyMWiAbQi1Pk+ hkGBKbArq8qHf5ETut6hAm3/a1Wke83+8V4ZiQI7xCRM6h/+/n7QGNRcExJAMNE+NjobcS +kmjZ7fy0+vHAUWAMQXqcXEqRLB4YLBDJ5s9UYTjFqPjxLR6/6PnJ7C77a5ffKXL/Dv7rQ uOO8F9vKl8kxdsQZ2mJ4yTJi/TM+qkJlPC1KqN++oAsZBmwYUTTgBwKU/wNnww== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1jpp0xJszHnf; Sun, 8 Sep 2024 08:30:58 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 5413B6557; Sun, 08 Sep 2024 09:30:57 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-60C8216D-1808-4A6F-B69D-FE6027DF7935 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 09:30:45 +0100 Message-Id: References: <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> Cc: freebsd-hackers@freebsd.org In-Reply-To: <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> To: Stefan Esser X-Mailer: iPad Mail (21G93) --Apple-Mail-60C8216D-1808-4A6F-B69D-FE6027DF7935 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7 Sep 2024, at 19:19, Stefan Esser wrote: >=20 > I have used netatalk for timemachine backups, do not remember why I > went back to using samba. Maybe I should try using netatalk again, > since then I could update samba to 3.19 for other file systems. This doc says that AFP was not supported for Time Machine after High Sierra /= APFS: https://support.apple.com/en-us/100765 If it=E2=80=99s not correct, I should probably go back to netatalk. David --Apple-Mail-60C8216D-1808-4A6F-B69D-FE6027DF7935 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 7= Sep 2024, at 19:19, Stefan Esser <se@freebsd.org> wrote:

I have used netatalk for timemachine backups, d= o not remember why I
went back to using samba. Maybe I shoul= d try using netatalk again,
since then I could update samba t= o 3.19 for other file systems.

This doc sa= ys that AFP was not supported for Time Machine after High Sierra / APFS:


If it=E2=80= =99s not correct, I should probably go back to netatalk.

David

= --Apple-Mail-60C8216D-1808-4A6F-B69D-FE6027DF7935-- From nobody Sun Sep 8 08:39:35 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 4X1k0r0l3Tz5WNyd for ; Sun, 08 Sep 2024 08:39:40 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1k0q0mJNz4X7w for ; Sun, 8 Sep 2024 08:39:39 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZpMitlir; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-42bbd16fcf2so29930435e9.2 for ; Sun, 08 Sep 2024 01:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725784777; x=1726389577; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=KXnsKNilK5hrzuOrcvhWYSf7cQiAGnPTx/ZGScuR50Q=; b=ZpMitlirDVRZmej2CcIeTdELmwC6LOz2jWc6sK07Bv51bhhWkVAky1y+mQmsAuYTmU y9+YWsighorfC/kUuIDLcfo5qz6Si46tR8sv1XM7tXX7lbmjIdMJgbgQu4mQ0N4rnir3 nCRXjNYViRlNfYmYmz81LX62wHvgrvb8LcJP/9XbiA9TfbgaLwzhafHlBgDNvxOicHQp g3rLTTs0pXKdxdpkpHC1jmOAnlOu3gBPjwK0Axm+MnKVBtk335YjIHScyaYo2S3tqN94 hNfxw02sV/0t0+CX74SPrKrVYlx1sWwZButhpkF4QPKBOpbud57+yzfFRX9g2L3K+7Bc vHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725784777; x=1726389577; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KXnsKNilK5hrzuOrcvhWYSf7cQiAGnPTx/ZGScuR50Q=; b=b56t8qxu5IvQGkt/M9lowsLGzDPBWGopiUXsxVmEfWv7CjPrNjOZIb3sCtKs4ulzL+ olEugMxcNixxOCJrp+mEZ0jqDF5Mfb6Ls1UMja+ZPZ/lo4FTL59IpouKoIWEEyh6ttRO tr2D1E6/qUQi/3PA8TpI0BAasooam/TZTiw7oXJOyObcupEnLgubyWuEh6qSioUzp6/8 3Ifir2VW42GlX2O21XVgge5aqe5RYta6BBohSDIMDV27mwtWssvQ+bYarQs+/5UcVFlV wlb3yXqEXoy5ir/nyi9tavaiQndDbQR+sV4f4GdVq+ZwF1K+vb6a2LeZO6M7OgaAJ7u3 aDSw== X-Gm-Message-State: AOJu0Yx89L/gI08GSKdjNM04Wod/liAjqNpcp4KgNoU9PL74O85ESFDw z5BDVYGXaglkrfHdyTxHhIgNha2NlzPAkcXoz3/3o+42v34QEUeWdKkMXg== X-Google-Smtp-Source: AGHT+IE0WEBhARvAcxdSb1v3xdHdTvmtDdRr3E1cxpBX/jQDRAaadRODuh1DDWPUo/saX/L/i19q8g== X-Received: by 2002:adf:fc0a:0:b0:374:c8dd:ea47 with SMTP id ffacd0b85a97d-37894a5ff7emr2491104f8f.50.1725784776557; Sun, 08 Sep 2024 01:39:36 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42cb099acf6sm33308695e9.9.2024.09.08.01.39.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Sep 2024 01:39:36 -0700 (PDT) Message-ID: <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com> Date: Sun, 8 Sep 2024 08:39:35 +0000 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: <20240905194529.3szOViVM@steffen%sdaoden.eu> Content-Language: en-US From: Paul Floyd In-Reply-To: <20240905194529.3szOViVM@steffen%sdaoden.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from] X-Rspamd-Queue-Id: 4X1k0q0mJNz4X7w On 05-09-24 19:45, Steffen Nurpmeso wrote: > Alan Somers wrote in > |The real takeaway here is that C is no longer sufficient for writing > |high quality code in the 2020s. Everyone needs to adapt their tools. > > I *totally* speak against this. > Quite the opposite i claim that C was safe already fifty years Is that a joke? Do you have any evidence? It sounds like wishful thinking to me. When I explain to my young colleagues that learnt to code in Java and Rust how K&R C function definitions "worked", their eyes open wide in amazement. > ago, it is just that the occasional one does not realize it. > *Nothing* prevents you from using a string object instead of > direct memory accesses, a vector object instead of arrays managed > via realloc(), and all that. *Nothing > If *you* do not do that that is your fault and you are a bad > programmer; moreover, you should not be allowed to vote in > a democratic environment (surely you do not read all the > magazines and newspapers, and watch or hear to policital > emissions, in order to build yourself a *real* opinion), be > enabled to drive a car, and what else not. I'm not sure that I follow your argument. Are you saying that you can build memory safety into C code and that if someone doesn't so they are a bad programmer? What's the point - why not just use a memory safe language? A+ Paul From nobody Sun Sep 8 08:52:51 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 4X1kJ66bZbz5WQWc for ; Sun, 08 Sep 2024 08:52:54 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1kJ61Vysz4ZNx for ; Sun, 8 Sep 2024 08:52:54 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=bKzgcvkO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-42c7856ed66so24508585e9.3 for ; Sun, 08 Sep 2024 01:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725785573; x=1726390373; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=W6Gz1S5V59HRzXpUYnyvOA5VuIxpteEoXj9faQs0c3I=; b=bKzgcvkO2nRmSzVMgCRQtuLr+1IeKzHwK5zSRPPq9cKPUv/RCOBJeD1dIc+XzvFwS2 0hyv267EFf0BNfIbI5sy5yWnrkRkluHk6M1wdaW564CQtp7+87AeRIuryox2t7otIdqp w8Wri3mh/hA98OD8JnS0+P9JRLFn6lcKSxl7nLyulyfbaO30dPb2NNpmOMeRYb5DevX1 XUrndlQJ9y/Oolx2Uaumx4gtnbR00OzowTkibog/OHNZD3AtriaL780TaLHFCj5+S5kM YKlUH1CfBKu/qT9+5TWkJmSGiNobu6YAQtjcDiTpvmB6w5Zp/A/EVaOifK1h+vY4y+hQ OayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725785573; x=1726390373; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W6Gz1S5V59HRzXpUYnyvOA5VuIxpteEoXj9faQs0c3I=; b=oCWlr6iEnQ/fMxyMuVJyStlLZrjkuD48XtKHtZGG9dq85jSVOX6jG/7YN/RaxazRze Rg8XS4yRhds3Y8vWifLPQa5oRgAAfvqBU4NPtTtS+y2VGRfsvITuMzcrBlxtNygDocIS T4uoFO5tMLWF4H9qNN720BXdTSzpoHxnIn1Mlmm31n45mnQazFMmcdmDtMpSOtv6P4bg YCX7Wrh0wzlLaxazo/CeN0V1isFp/4Lj2qJ4734DDj9Tq8jfSMVBUOlbzvfIzhfUAQFL w/S5tFYtQuJmedWhvYNRhpwRv4JQ5WnWnuUjoriy+hhg957IzqoW4WVef2bNMYQ1HyMI XiRA== X-Gm-Message-State: AOJu0Yy8NQoquFWUweU32jZZjMBLU00kiQ+OP5p2lyiMbqkTe/VYGwYf 5wSVSzsoKldohJTkkzq+8kBzbOTzFyrRaWDGHGAgzD7bJiwbZ9ReB0litA== X-Google-Smtp-Source: AGHT+IFHn/93EckepsAtvAIzhthkjVg3hupN5qvYn7LIMEjMzsPzT7mcDI+FgMGnAk8zdmzYs0/A1w== X-Received: by 2002:a05:600c:3d93:b0:426:62c5:4742 with SMTP id 5b1f17b1804b1-42cad74649emr30222375e9.7.1725785572475; Sun, 08 Sep 2024 01:52:52 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42caeb21d2fsm38459695e9.1.2024.09.08.01.52.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Sep 2024 01:52:52 -0700 (PDT) Message-ID: <9fea8629-87f7-46a1-ad33-06a82271cd79@gmail.com> Date: Sun, 8 Sep 2024 08:52:51 +0000 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 User-Agent: Mozilla Thunderbird From: Paul Floyd Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org References: <4634B979-4EB9-41AE-A9FE-14ACC9A4324A@iitbombay.org> Content-Language: en-US In-Reply-To: <4634B979-4EB9-41AE-A9FE-14ACC9A4324A@iitbombay.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from] X-Rspamd-Queue-Id: 4X1kJ61Vysz4ZNx On 05-09-24 20:21, Bakul Shah wrote: > On Sep 5, 2024, at 11:34 AM, Tomek CEDRO wrote: >> >> wow! this is undeniable argument even for someone who opposes the idea (like me) :-) > > Not really! > > Showing that a present system has issues does not imply in any > way that a proposed new system (or major change) will fix the > said problems! This is a common fallacy that people fall for. > Many people. Many many people :-) I don't think that anyone is saying that we should stop the world and rewrite it in Rust (or C++). Herb Sutter (convenor of the C++ standard committee wrote a good article on this recently: https://accu.org/journals/overload/32/180/sutter/ Notable points - only 4 of of the top 12 CWEs are due to memory safety. - switching existing code to MSLs would need a magic wand and still wouldn't make all problems go away. - make good use of other tools like analyzers and sanitizers A+ Paul From nobody Sun Sep 8 08:53:57 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 4X1kKY1Jmxz5WR05 for ; Sun, 08 Sep 2024 08:54:09 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X1kKY0N9Nz4b8X; Sun, 8 Sep 2024 08:54:09 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725785649; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fv0R2cEL6sbtA9niIe1mbaSWKe2aSZl2+u1graIFWac=; b=o9FPhC2ScV+hVidqD4BgnIEqWhqF6QAaKwLIgK1WQl0x9xuVciQdjALlFLhIovU+Qt+Yej ipyBcKeHdOpvfZTAPcHB/UqRrSfFF5yrvvF9upeB0T7biWyArupb8fcYbvFWH2NAMm6up6 pQ3tCH0HJz8BYdLOdPOXs931l+jNkTtwBJx+uvEUBtVGOchbRVqTTadDx+ZdFKlLKaeicB h6U0Su+CFNMKs9aUt5J67Ux90zGHpwn8RV0ibmrh5SGKCjixWh4VGwKd5kCcpqmiq2XdEm T5GPSgNTGL4XFqHi3LkzklHC5E5htBP/XDaHaVp/WtKXzoCpC9wi45vn4DxIqg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725785649; a=rsa-sha256; cv=none; b=ZxwgOEN52xIsO/kUbSCWtkE82YVYIud9Fz8alT07gIsZG1xsRtm5pB1K1Ffe6BdAB1HMkQ hG1D/2YIFhLZHI6oFomsnb79RD8pWwm3NlITNoVROf6RegN1NXQtvPVo/XnjGFv0Zbfizu yqIqh4KwnfZ18+4/AOoH6Yl8pVVouDtHzeRCn/+zLqvIpBJFy/ofo27sM68nacji/KCr8f sKJSfp+yYOGptm8sQ/qmUQjfBlY9uKi/rEMlqI8mDo/Q/im01JvOMTo9Kk24Dps63P23v7 fBfcJ9Fyp69C4JZfRJTjERYS5VWy2YgzBbhV1MKcytHcgRVFwSnqVPYsHnj7rw== 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=1725785649; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fv0R2cEL6sbtA9niIe1mbaSWKe2aSZl2+u1graIFWac=; b=Tw6FYf45lz0mAErzWKNo8IoqVmOxfLGr9598fus3i1WLZ49lCBJ1QwS7/rWfbQwr5QiIw9 Aqb/UKAX6jFDsbt3amR//ONJK1ElBc+bI7Z3PTXLS9RQxYRHikjr5PuYbxhh8z0c1njhd9 jmVTqoKkbsTvn7gNQZOKDgOycnqONmOoxZQ1TgBuQtP5OfBviDc9xGgvrJAckIdPTQ8lkY a//dKRKYK0HVJZk8pRbF3a5+JNkrKdlqqwK5/5z8IPgqZ20O4y22tKA7DUX22So4l0PX4B gDzgWA1ufX7zhKi8wHlwjdhV/Tm/jTZN2xIKZvlHfb6qdCpsE9YcMqMy34FQvw== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1kKX6wnnzKQ6; Sun, 8 Sep 2024 08:54:08 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7C0816558; Sun, 08 Sep 2024 09:54:08 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: CHERIoT RTOS C++ [Re: The Case for Rust (in any system)] Date: Sun, 8 Sep 2024 09:53:57 +0100 Message-Id: References: <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.com> Cc: freebsd-hackers@freebsd.org In-Reply-To: <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.com> To: Paul Floyd X-Mailer: iPad Mail (21G93) --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Changing the title so people who don=E2=80=99t care can easily ignore this t= angent. > On 7 Sep 2024, at 20:20, Paul Floyd wrote: >=20 > Out of curiosity, did that mean limiting the ABI use (no RTTI or exception= s). Did it also allow using different compilers (say clang and GCC)? We=E2=80=99re targeting tiny embedded systems. The total code size for the c= ore RTOS (scheduler, memory allocator, switcher) is around 10 KiB, so except= ions are totally infeasible. A stack unwinded would be as big as the total a= mount of RAM on some of the SoCs we want to be able to support. We also don=E2= =80=99t use RTTI for a similar reason. We do have a tiny C++ runtime for laz= y static initialisation. I wish the C++ standard would lose its allergy to subsetting, because the st= andard not subsetting does not prevent it happening, it just means everyone d= oes it differently. In terms of library support, we claim to be a freestandi= ng implementation and also provide a bunch of things from hosted implementat= ions. A lot of the normal standard library types are not well suited to envi= ronments where memory allocation can fail and where exceptions don=E2=80=99t= work (the libc++ code calls abort in these cases, we want things that retur= n std::optional for things that might fail). We are co-designing the hardware and software. We have some FPGA prototyping= platforms (lowRISC has built a really nice one) and the company I cofounded= will ship commercial silicon next year. We have some extensions beyond CHER= I that enable deterministic heap temporal safety as well. As soon as you fre= e an object, all pointers to it become unusable (and then we have some addit= ional hardware that makes it possible to safely reuse the memory).=20 So it=E2=80=99s not quite normal C++. We can inspect a pointer and tell what= its bounds are, what its permissions are, and whether it=E2=80=99s valid. W= e can also transform it into a tamper-proof =E2=80=98sealed=E2=80=99 pointer= that can be unsealed only if you hold the relevant unsealing token. This ca= n protect things like socket handles: the TCP/IP stack hands out a sealed po= inter to the socket state and can check when you pass it back that it is the= correct type and can then unseal it, but you everything else that pointer i= s a value that can be copied around but can=E2=80=99t be used. We can do som= e fun things (it=E2=80=99s possible to represent all of the state of a std::= vector with a single pointer, for example) and, in some places, we skip stat= ic memory safety checks and instead write code that expects to fail and retu= rn to the calling compartment if it encounters a memory-safety bug. This set of primitives lets us build a rich compartmentalisation model where= communication between compartments looks like a function call and sharing m= emory is accomplished by passing pointers (which may have restricted permiss= ions, including shallow or deep immutability and no-capture guarantees). On t= op of this, we have built auditing tooling that lets you see which compartme= nts call which entry points in others, which compartments have access to whi= ch MMIO regions, and so on. Our ABI defines a bunch of things that are extensions to the Itanium ABI suc= h as calling conventions for cross-compartment calls, shared libraries (whic= h, for us, are stateless and don=E2=80=99t involve a security domain crossin= g, whereas compartments do). We don=E2=80=99t have support for more than one compiler at the moment becau= se our extensions are implemented only in clang. There is nothing stopping a= nyone adding the same support in other compilers though and I=E2=80=99d be h= appy to help anyone who wanted to do gcc bring up. More details (code, formal model of the ISA, programmers=E2=80=99 handbook, a= nd so on here): https://cheriot.org/ David --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Cha= nging the title so people who don=E2=80=99t care can easily ignore this tang= ent.

On 7 Sep 2024, at 20:20, Paul Floyd <paulf2718@gmail.com> wrote:
Out of c= uriosity, did that mean limiting the ABI use (no RTTI or exceptions). Did it= also allow using different compilers (say clang and GCC)?

We=E2=80=99re targeting tiny embedded systems. The total code size= for the core RTOS (scheduler, memory allocator, switcher) is around 10 KiB,= so exceptions are totally infeasible. A stack unwinded would be as big as t= he total amount of RAM on some of the SoCs we want to be able to support. We= also don=E2=80=99t use RTTI for a similar reason. We do have a tiny C++ run= time for lazy static initialisation.

I wish the C++= standard would lose its allergy to subsetting, because the standard not sub= setting does not prevent it happening, it just means everyone does it differ= ently. In terms of library support, we claim to be a freestanding implementa= tion and also provide a bunch of things from hosted implementations. A lot o= f the normal standard library types are not well suited to environments wher= e memory allocation can fail and where exceptions don=E2=80=99t work (the li= bc++ code calls abort in these cases, we want things that return std::option= al for things that might fail).

We are co-designing= the hardware and software. We have some FPGA prototyping platforms (lowRISC= has built a really nice one) and the company I cofounded will ship commerci= al silicon next year. We have some extensions beyond CHERI that enable deter= ministic heap temporal safety as well. As soon as you free an object, all po= inters to it become unusable (and then we have some additional hardware that= makes it possible to safely reuse the memory). 

So it=E2=80=99s not quite normal C++. We can inspect a pointer and tell w= hat its bounds are, what its permissions are, and whether it=E2=80=99s valid= . We can also transform it into a tamper-proof =E2=80=98sealed=E2=80=99 poin= ter that can be unsealed only if you hold the relevant unsealing token. This= can protect things like socket handles: the TCP/IP stack hands out a sealed= pointer to the socket state and can check when you pass it back that it is t= he correct type and can then unseal it, but you everything else that pointer= is a value that can be copied around but can=E2=80=99t be used. We can do s= ome fun things (it=E2=80=99s possible to represent all of the state of a std= ::vector with a single pointer, for example) and, in some places, we skip st= atic memory safety checks and instead write code that expects to fail and re= turn to the calling compartment if it encounters a memory-safety bug.
<= div>
This set of primitives lets us build a rich compartmental= isation model where communication between compartments looks like a function= call and sharing memory is accomplished by passing pointers (which may have= restricted permissions, including shallow or deep immutability and no-captu= re guarantees). On top of this, we have built auditing tooling that lets you= see which compartments call which entry points in others, which compartment= s have access to which MMIO regions, and so on.

Our= ABI defines a bunch of things that are extensions to the Itanium ABI such a= s calling conventions for cross-compartment calls, shared libraries (which, f= or us, are stateless and don=E2=80=99t involve a security domain crossing, w= hereas compartments do).

We don=E2=80=99t have supp= ort for more than one compiler at the moment because our extensions are impl= emented only in clang. There is nothing stopping anyone adding the same supp= ort in other compilers though and I=E2=80=99d be happy to help anyone who wa= nted to do gcc bring up.

More details (code, formal= model of the ISA, programmers=E2=80=99 handbook, and so on here):

https://cheriot.org/

David

= --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397-- From nobody Sun Sep 8 11:48:13 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 4X1pBd5zwrz5TbkW for ; Sun, 08 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@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 4X1pBd5Q7Lz4vkm; Sun, 8 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725796105; 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=w0RG6a77cV8hK2EcolEvlpHIBD/EWZ+92pBAhN8DIJQ=; b=yCEd7P2C2oGYIY5zNktZhw/xWwHp6ObV3O/Vyq7wALzAYy/C6D1IZTg3JC/+eGpyyxNUQ2 cvoTZZ0t4BCJLhI92TWjyWAJy/5aWDac8Ctf0rb51My/5Onm4ypBZKvm17FJ7Y30xpEj4M NFuL5hmd6OpS2rWYRIplC30jkO78UodeovugC3R6N+76wkAjePM+upg8Z+G/oZMUCk0xY1 IA6RO9Es4C1Wsr6+vvywDADAo4Cv75ixP5R5GY9xmxC1FxTxf0NFnyEmn+DP7mIJLxp/IM ESZcYLqFqMc1yjfPcGzu6/F6m2JQ7qSfh6XS9Oqq5V7BVxQ7EAmtv2ekvXo8lA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725796105; a=rsa-sha256; cv=none; b=Pt0dQuKAyhXN/HySTdsne+YTcQ1Rrxhd7HmZo2MLnAZ74CmhoS8KJ8eSC5hyihCWh5k3fV 0HAl1R5oxxZY6X+H2qZ0d57ngq2vEY/rqMl0ohjptvkxwdqwi7QnITa6nXIZdffTlSys4v /JtkE0466FVv8u338kyf2mWRRlP+CQ26KCwTZIwKgLyUXl5dd8NmnOvwbo4XtfzffyPNau zAJl7NZ30SzL1S8LsZBAvlUqhkmTuPYvCTG1gNbrRChvMyWI0kbWOhsm5nVSWK9rmH9kS4 4OoTe/pGGJcqdOf9EM1THgBk6kpMPYhDer4G2mg7lgPvN5Mw5/ZNy5TV61ncsQ== 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=1725796105; 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=w0RG6a77cV8hK2EcolEvlpHIBD/EWZ+92pBAhN8DIJQ=; b=WNGXK9t2u45GYdhIrepM/8OpdbgEb6EDUAkKrE7nIbY2n8wLCQhSZU8b27eBEwQNe4AUcH zQbdoybek+K16JVnq3+z+Uhb6jU5Ba3jxNj4AtmogyCU1ocnu0vUR2Rnw2h4GJDTFrIrkQ O2ZqsMmOJtPT+KEIDICeYcA26z6mdRm6920AcLAmukpNKfmfvGZSlZwhX6raSclywhsfQU r3JSm2frMNE6sqOBPNpW3e4cNAgJNr9N3hZOgVHlEx3RxkzId6sjFyIK7RX3OQEIjsnNY5 D31HZWJa+aZDPAujQOOiM6r+HGtJgaheFKLXw8cpc9VLX2MCKTqnN1AYGh8ZjA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1pBd4qJfzNpM; Sun, 8 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 5F08D655D; Sun, 08 Sep 2024 12:48:24 +0100 (BST) From: David Chisnall Message-Id: <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 12:48:13 +0100 In-Reply-To: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> Cc: freebsd-hackers@freebsd.org To: Craig Leres References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A little bit more debugging, and a working hypothesis: I have tried creating a new Time Machine share (empty directory) and = pointing the Mac at it. On the first backup, it creates a = `.com.apple.timemachine.supported-{uuid}` file and a = `{uuid}-{date}.sparsebundle` directory. It appears to create a valid = sparse bundle, but other posts suggest that it then renames this to = `{computername}.backupbundle`. There is a Samba setting: = `fruit:posix_rename` that is supposed to control this. It appears to = fail at the point where it should do this rename. =20 If I mount the same share, I can reproduce this: $ mkdir tmp $ touch tmp/foo $ mv tmp fmp mv: rename tmp to fmp: Operation not supported So it appears that something in the FreeBSD port of Samba has broken the = ability to rename directories. =20 This appears to be recent breakage. Reverying to net/samba416 fixes = this bit, at least, and I can now back up to a pristine share. David > On 7 Sep 2024, at 08:28, David Chisnall wrote: >=20 > I believe this was broken by a macOS update around February. I=E2=80=99v= e been trying to debug for a while. I=E2=80=99ve opened an Apple issue = (FB14500950, for any Apple folks) but it shows up as few people = reporting it. I posted on Mastodon and several people reported that Time = Machine is broken and recommended Carbon Copy Cloner as an alternative. = I would like to see it fixed, but it probably needs some more debugging = by Apple folks.=20 >=20 > It stopped working for me with no changes on the server and I can = reproduce the failures on two different Macs. >=20 > Things I have tried: >=20 > - Upgrading Samba from 4.16 to 4.19 > - Upgrading FreeBSD from 13.x to 14.1 > - Setting the SMB timeout sysctls to larger values on macOS. > - Turning up the SMB debug sysctls on macOS to see if there=E2=80=99s = more info > - Turning up the Samba logging level. > - Verifying the backups > - Watching smbinfo the server. > - Updating macOS to the latest version > - Connecting to the server with Finder and checking I can access = files on the shares and that they have the right permissions. >=20 > Samba doesn=E2=80=99t report any errors (I don=E2=80=99t know if = there=E2=80=99s a way to force Samba to report permission-denied = things). >=20 > It appears that the Mac acquires a load of read-only locks and so does = a lot of reads, but for some reason it appears to fail the first write. = Even with a verify, it looks like it completes the verification bit but = then fails to write to the plist file.=20 >=20 > With the increased debugging, I see this in the macOS Comsole: >=20 > default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 > default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 > default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 > default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 > default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs > default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 > default 14:12:26.542682+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied > default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 > default 14:12:26.543657+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied > default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 > default 14:12:26.543697+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied > default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 > default 14:12:26.543730+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied > default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >=20 > So it looks as if it is a permission issue. Maybe the mcOS SMB client = has started using some bit of the protocol that Samba on FreeBSD = doesn=E2=80=99t support for ACLs? >=20 > David >=20 >> On 6 Sep 2024, at 22:48, Craig Leres wrote: >>=20 >> =EF=BB=BFLast year you guys helped me get this to work with samba416. = I recently tried to upgrade to samba419 and so far I'm unsuccessful. The = error is "The backup disk image could not be created" and I'm running = 14.1. >>=20 >> I'm using the same port build options with 4.16 and 4.19: >>=20 >> FAM >> PYTHON3 >> QUOTAS >> SYSLOG >> UTMP >> GSSAPI_BUILTIN >> AVAHI >> FRUIT >>=20 >> Having learned my lesson when I upgraded from 4.13 to 4.16, I removed = the old backups from the zfs volume on the server before starting. I've = also learned the rule that you need to delete and reattach the share on = the mac side when you change the samba config. >>=20 >> Appended is the config that works with 4.16 (but not 4.19) >>=20 >> Craig >>=20 >> [global] >> workgroup =3D XYZ >> security =3D user >> netbios name =3D red >> server string =3D red.example.net >> hostname lookups =3D no >> server role =3D standalone server >>=20 >> interfaces =3D ixl0 lo0 >> bind interfaces only =3D yes >>=20 >> load printers =3D no >> show add printer wizard =3D no >> time server =3D yes >> use mmap =3D yes >>=20 >> dos charset =3D 850 >> unix charset =3D UTF-8 >> mangled names =3D no >>=20 >> #log level =3D 3 >> #log file =3D /tmp/samba.log >> vfs objects =3D catia fruit streams_xattr zfsacl >>=20 >> fruit:model =3D MacSamba >> fruit:resource =3D file >> fruit:metadata =3D netatalk >> fruit:nfs_aces =3D yes >> fruit:copyfile =3D no >> fruit:aapl =3D yes >> fruit:zero_file_id =3D yes >>=20 >> inherit permissions =3D yes >>=20 >>=20 >> [Time Machine] >> path =3D /backups/mini >> read only =3D no >> guest ok =3D no >> writeable =3D yes >> browseable =3D yes >> fruit:resource =3D file >> fruit:time machine =3D yes >> valid users =3D backup-mini >> max disk size 512G >>=20 >> hosts allow =3D 10.0.0.19 >>=20 --Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A little bit = more debugging, and a working hypothesis:

I have = tried creating a new Time Machine share (empty directory) and pointing = the Mac at it.  On the first backup, it creates a = `.com.apple.timemachine.supported-{uuid}` file and a = `{uuid}-{date}.sparsebundle` directory.  It appears to create a = valid sparse bundle, but other posts suggest that it then renames this = to `{computername}.backupbundle`.  There is a Samba setting: = `fruit:posix_rename` that is supposed to control this.  It appears = to fail at the point where it should do this rename. =  

If I mount the same share, I can = reproduce this:

$ mkdir tmp
$ = touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: = Operation not supported

So it appears = that something in the FreeBSD port of Samba has broken the ability to = rename directories.  

This appears to be = recent breakage.  Reverying to net/samba416 fixes this bit, at = least, and I can now back up to a pristine = share.

David

On 7 Sep 2024, at 08:28, David Chisnall = <theraven@FreeBSD.org> wrote:

I believe this was broken by a macOS = update around February. I=E2=80=99ve been trying to debug for a while. = I=E2=80=99ve opened an Apple issue (FB14500950, for any Apple folks) but = it shows up as few people reporting it. I posted on Mastodon and several = people reported that Time Machine is broken and recommended Carbon Copy = Cloner as an alternative. I would like to see it fixed, but it probably = needs some more debugging by Apple folks. 

It stopped working for me with no = changes on the server and I can reproduce the failures on two different = Macs.

Things I have = tried:

 - = Upgrading Samba from 4.16 to 4.19
 - = Upgrading FreeBSD from 13.x to 14.1
 - = Setting the SMB timeout sysctls to larger values on macOS.
 - Turning up the SMB debug sysctls on macOS to see if = there=E2=80=99s more info
 - Turning up the = Samba logging level.
 - Verifying the = backups
 - Watching smbinfo the = server.
 - Updating macOS to the latest = version
 - Connecting to the server with = Finder and checking I can access files on the shares and that they have = the right permissions.

Samba doesn=E2=80=99t report any errors (I don=E2=80=99t = know if there=E2=80=99s a way to force Samba to report permission-denied = things).

It appears = that the Mac acquires a load of read-only locks and so does a lot of = reads, but for some reason it appears to fail the first write. Even with = a verify, it looks like it completes the verification bit but then fails = to write to the plist file. 

With the increased debugging, I see this in the macOS = Comsole:

default 14:12:26.297714+0100 = kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13 default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80

So it looks as if it is a = permission issue. Maybe the mcOS SMB client has started using some bit = of the protocol that Samba on FreeBSD doesn=E2=80=99t support for = ACLs?

David

On 6 Sep 2024, at 22:48, Craig = Leres <leres@freebsd.org> = wrote:

=EF=BB=BFLast year you guys helped me get this to work = with samba416. I recently tried to upgrade to samba419 and so far I'm = unsuccessful. The error is "The backup disk image could not be created" = and I'm running 14.1.

I'm using the = same port build options with 4.16 and = 4.19:

=    FAM
=    PYTHON3
=    QUOTAS
=    SYSLOG
=    UTMP
=    GSSAPI_BUILTIN
=    AVAHI
=    FRUIT

Having learned = my lesson when I upgraded from 4.13 to 4.16, I removed the old backups = from the zfs volume on the server before starting. I've also learned the = rule that you need to delete and reattach the share on the mac side when = you change the samba config.

Appended = is the config that works with 4.16 (but not = 4.19)

      =  Craig

[global]
=    workgroup =3D XYZ
=    security =3D user
=    netbios name =3D red
=    server string =3D red.example.net
=    hostname lookups =3D no
=    server role =3D standalone = server

   interfaces =3D = ixl0 lo0
   bind interfaces only =3D = yes

   load printers =3D = no
   show add printer wizard =3D = no
   time server =3D = yes
   use mmap =3D = yes

   dos charset =3D = 850
   unix charset =3D = UTF-8
   mangled names =3D = no

   #log level =3D = 3
   #log file =3D = /tmp/samba.log
   vfs objects =3D catia = fruit streams_xattr zfsacl

=    fruit:model =3D MacSamba
=    fruit:resource =3D file
=    fruit:metadata =3D netatalk
=    fruit:nfs_aces =3D yes
=    fruit:copyfile =3D no
=    fruit:aapl =3D yes
=    fruit:zero_file_id =3D = yes

   inherit = permissions =3D = yes


[Time = Machine]
   path =3D = /backups/mini
   read only =3D = no
   guest ok =3D no
=    writeable =3D yes
=    browseable =3D yes
=    fruit:resource =3D file
=    fruit:time machine =3D yes
=    valid users =3D backup-mini
=    max disk size 512G

=    hosts allow =3D = 10.0.0.19


= --Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289-- From nobody Sun Sep 8 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-- From nobody Sun Sep 8 12:10:29 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 4X1phK1jl7z5Tfqk for ; Sun, 08 Sep 2024 12:10:41 +0000 (UTC) (envelope-from theraven@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 4X1phK1QYFz5159; Sun, 8 Sep 2024 12:10:41 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725797441; 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=vUcwaxhOBJsMr40uB+Jw+QVkTlaAddWL7WcxiS4vrqM=; b=ouhusGIq3c06PrGkBFQ8JStir9NHwjzHwvRYoiLunwCzckBgw/yJ51Kmi7y5mWPrcchlR3 C6ZCIOds5LCmX81QnqXtXm0DS09VJSZc6iw3/pJiOSReClqIczvsBk4Elji89f3eP1Q4ji 5l5FxJKusHDLwRBHXatpBgaNGtByGA8NaYE3cOMkQnJ8+0wKEBQvMeHhl7nz8ia2PJQ7Ap 2vCg8SyPL4bN3Aw//liVTUo9rM3Rd1MTt5sPrZ9+uTntaYi72Hloe8ioReD0D0M5TANGcr HYwzubLrVpWOlYcLpp6RbgPd7X3mhUsEBARLxmdtFnIEAK5bSAKAoq8wh6LbGA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725797441; a=rsa-sha256; cv=none; b=JdkjhmORgfThahsty3Akl39EGJvD1XY2mlMcyaLxZ8NcYYg3u89hAXEu1RpUPFBGPsDZAt 8BxcibV+RCxqKMJmIo7TAwSvvqjd+FXtGrm0pQLcMFMyxx04RWkCCc4c1V43MzKZOaHzd/ jg1dQiP8av+KcaWPtsu3BuF0kUWgZ3C4otOGlzdW/5KtgDioVTRhImXgmDXgSjcXxP1XFq Jw+N8ZoRnqfo4qyyNIG1QhTsLRCjzMWbBCh3WDFxBZqkAS5ejTPTD0Jo7IWyJO13/ZO67i jYfk4xbPbL1BnAoi4GWAoPtG6FtcH8lRt2lZAvzU6AvD500hqmr3LcJAYvJDug== 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=1725797441; 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=vUcwaxhOBJsMr40uB+Jw+QVkTlaAddWL7WcxiS4vrqM=; b=e2WJpik5e7jwAAdq9nnjjvHsendOuImB72hpcAkc58DynVMfpGBTZTLoP0H1tXE7QxPgH4 xpYNwtDPFmbgrSlc3jsTK5LC5xhI/nkZMSpmRW7DbHUcUXJEpAz1Rc7k3JXJZ4AMnCwuC6 A2hzD+bQbkNeMuEGVMffkFP1ydvfs466rLJrC7H8zDhi9D8gMAdnrchrrSuZUdct3+0Qj6 QqZEXV4Uz4Kg3LRBD5TzhQ5+csPytGNEk/09av6Pqc5ayrlEq/YSN2q6cx9/ryIvv7kBt2 7/4whtcz8m3ayfCYj9S9FO53r/bDmAVl0PxYGxe39IsAtOA6iJJ/HHUuxpyDag== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1phK0r3SzPZx; Sun, 8 Sep 2024 12:10:41 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 68AC2655E; Sun, 08 Sep 2024 13:10:40 +0100 (BST) From: David Chisnall Message-Id: <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_77A5D516-896F-451A-85CC-D471D0F0682F" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 13:10:29 +0100 In-Reply-To: <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> Cc: freebsd-hackers@freebsd.org To: Craig Leres References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_77A5D516-896F-451A-85CC-D471D0F0682F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360 = to track this. Reverting to samba416, I can back up in a new share, but I cannot back = up to the share that had my existing backups in it. This may be a = permissions issue or some problem withe metadata getting out of sync: = moving the backupbundle from the old share to the new one does not fix = it. Once I have a new complete backup, I will try comparing the = metadata and seeing what the differences are. So far, the main difference appears to be that the new backup creates a = disk image bundle with 500 MiB bands whereas the old one was using 8 MiB = bands. This change is presumably because APFS, unlike HFS+, supports = holes in files, but I wonder if there=E2=80=99s a problem with Samba and = very large directories? There were 47,486 bands in the old disk image. David > On 8 Sep 2024, at 12:48, David Chisnall wrote: >=20 > A little bit more debugging, and a working hypothesis: >=20 > I have tried creating a new Time Machine share (empty directory) and = pointing the Mac at it. On the first backup, it creates a = `.com.apple.timemachine.supported-{uuid}` file and a = `{uuid}-{date}.sparsebundle` directory. It appears to create a valid = sparse bundle, but other posts suggest that it then renames this to = `{computername}.backupbundle`. There is a Samba setting: = `fruit:posix_rename` that is supposed to control this. It appears to = fail at the point where it should do this rename. =20 >=20 > If I mount the same share, I can reproduce this: >=20 > $ mkdir tmp > $ touch tmp/foo > $ mv tmp fmp > mv: rename tmp to fmp: Operation not supported >=20 > So it appears that something in the FreeBSD port of Samba has broken = the ability to rename directories. =20 >=20 > This appears to be recent breakage. Reverying to net/samba416 fixes = this bit, at least, and I can now back up to a pristine share. >=20 > David >=20 >> On 7 Sep 2024, at 08:28, David Chisnall wrote: >>=20 >> I believe this was broken by a macOS update around February. I=E2=80=99= ve been trying to debug for a while. I=E2=80=99ve opened an Apple issue = (FB14500950, for any Apple folks) but it shows up as few people = reporting it. I posted on Mastodon and several people reported that Time = Machine is broken and recommended Carbon Copy Cloner as an alternative. = I would like to see it fixed, but it probably needs some more debugging = by Apple folks.=20 >>=20 >> It stopped working for me with no changes on the server and I can = reproduce the failures on two different Macs. >>=20 >> Things I have tried: >>=20 >> - Upgrading Samba from 4.16 to 4.19 >> - Upgrading FreeBSD from 13.x to 14.1 >> - Setting the SMB timeout sysctls to larger values on macOS. >> - Turning up the SMB debug sysctls on macOS to see if there=E2=80=99s = more info >> - Turning up the Samba logging level. >> - Verifying the backups >> - Watching smbinfo the server. >> - Updating macOS to the latest version >> - Connecting to the server with Finder and checking I can access = files on the shares and that they have the right permissions. >>=20 >> Samba doesn=E2=80=99t report any errors (I don=E2=80=99t know if = there=E2=80=99s a way to force Samba to report permission-denied = things). >>=20 >> It appears that the Mac acquires a load of read-only locks and so = does a lot of reads, but for some reason it appears to fail the first = write. Even with a verify, it looks like it completes the verification = bit but then fails to write to the plist file.=20 >>=20 >> With the increased debugging, I see this in the macOS Comsole: >>=20 >> default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 >> default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 >> default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 >> default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 >> default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs >> default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >> default 14:12:26.542682+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >> default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >> default 14:12:26.543657+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >> default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >> default 14:12:26.543697+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >> default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >> default 14:12:26.543730+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >> default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>=20 >> So it looks as if it is a permission issue. Maybe the mcOS SMB client = has started using some bit of the protocol that Samba on FreeBSD = doesn=E2=80=99t support for ACLs? >>=20 >> David >>=20 >>> On 6 Sep 2024, at 22:48, Craig Leres wrote: >>>=20 >>> =EF=BB=BFLast year you guys helped me get this to work with = samba416. I recently tried to upgrade to samba419 and so far I'm = unsuccessful. The error is "The backup disk image could not be created" = and I'm running 14.1. >>>=20 >>> I'm using the same port build options with 4.16 and 4.19: >>>=20 >>> FAM >>> PYTHON3 >>> QUOTAS >>> SYSLOG >>> UTMP >>> GSSAPI_BUILTIN >>> AVAHI >>> FRUIT >>>=20 >>> Having learned my lesson when I upgraded from 4.13 to 4.16, I = removed the old backups from the zfs volume on the server before = starting. I've also learned the rule that you need to delete and = reattach the share on the mac side when you change the samba config. >>>=20 >>> Appended is the config that works with 4.16 (but not 4.19) >>>=20 >>> Craig >>>=20 >>> [global] >>> workgroup =3D XYZ >>> security =3D user >>> netbios name =3D red >>> server string =3D red.example.net >>> hostname lookups =3D no >>> server role =3D standalone server >>>=20 >>> interfaces =3D ixl0 lo0 >>> bind interfaces only =3D yes >>>=20 >>> load printers =3D no >>> show add printer wizard =3D no >>> time server =3D yes >>> use mmap =3D yes >>>=20 >>> dos charset =3D 850 >>> unix charset =3D UTF-8 >>> mangled names =3D no >>>=20 >>> #log level =3D 3 >>> #log file =3D /tmp/samba.log >>> vfs objects =3D catia fruit streams_xattr zfsacl >>>=20 >>> fruit:model =3D MacSamba >>> fruit:resource =3D file >>> fruit:metadata =3D netatalk >>> fruit:nfs_aces =3D yes >>> fruit:copyfile =3D no >>> fruit:aapl =3D yes >>> fruit:zero_file_id =3D yes >>>=20 >>> inherit permissions =3D yes >>>=20 >>>=20 >>> [Time Machine] >>> path =3D /backups/mini >>> read only =3D no >>> guest ok =3D no >>> writeable =3D yes >>> browseable =3D yes >>> fruit:resource =3D file >>> fruit:time machine =3D yes >>> valid users =3D backup-mini >>> max disk size 512G >>>=20 >>> hosts allow =3D 10.0.0.19 >>>=20 >=20 --Apple-Mail=_77A5D516-896F-451A-85CC-D471D0F0682F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have = opened https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360 to track = this.

Reverting to samba416, I can back up in a new = share, but I cannot back up to the share that had my existing backups in = it.  This may be a permissions issue or some problem withe metadata = getting out of sync: moving the backupbundle from the old share to the = new one does not fix it.  Once I have a new complete backup, I will = try comparing the metadata and seeing what the differences = are.

So far, the main difference appears to be = that the new backup creates a disk image bundle with 500 MiB bands = whereas the old one was using 8 MiB bands.  This change is = presumably because APFS, unlike HFS+, supports holes in files, but I = wonder if there=E2=80=99s a problem with Samba and very large = directories?  There were 47,486 bands in the old disk = image.

David

On 8 Sep 2024, at 12:48, David Chisnall = <theraven@FreeBSD.org> wrote:

A = little bit more debugging, and a working = hypothesis:

I have tried creating a new Time Machine = share (empty directory) and pointing the Mac at it.  On the first = backup, it creates a `.com.apple.timemachine.supported-{uuid}` file and = a `{uuid}-{date}.sparsebundle` directory.  It appears to create a = valid sparse bundle, but other posts suggest that it then renames this = to `{computername}.backupbundle`.  There is a Samba setting: = `fruit:posix_rename` that is supposed to control this.  It appears = to fail at the point where it should do this rename. =  

If I mount the same share, I can = reproduce this:

$ mkdir tmp
$ = touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: = Operation not supported

So it appears = that something in the FreeBSD port of Samba has broken the ability to = rename directories.  

This appears to be = recent breakage.  Reverying to net/samba416 fixes this bit, at = least, and I can now back up to a pristine = share.

David

On 7 Sep 2024, at 08:28, David Chisnall = <theraven@FreeBSD.org> wrote:

I believe this was broken by a macOS = update around February. I=E2=80=99ve been trying to debug for a while. = I=E2=80=99ve opened an Apple issue (FB14500950, for any Apple folks) but = it shows up as few people reporting it. I posted on Mastodon and several = people reported that Time Machine is broken and recommended Carbon Copy = Cloner as an alternative. I would like to see it fixed, but it probably = needs some more debugging by Apple folks. 

It stopped working for me with no = changes on the server and I can reproduce the failures on two different = Macs.

Things I have = tried:

 - = Upgrading Samba from 4.16 to 4.19
 - = Upgrading FreeBSD from 13.x to 14.1
 - = Setting the SMB timeout sysctls to larger values on macOS.
 - Turning up the SMB debug sysctls on macOS to see if = there=E2=80=99s more info
 - Turning up the = Samba logging level.
 - Verifying the = backups
 - Watching smbinfo the = server.
 - Updating macOS to the latest = version
 - Connecting to the server with = Finder and checking I can access files on the shares and that they have = the right permissions.

Samba doesn=E2=80=99t report any errors (I don=E2=80=99t = know if there=E2=80=99s a way to force Samba to report permission-denied = things).

It appears = that the Mac acquires a load of read-only locks and so does a lot of = reads, but for some reason it appears to fail the first write. Even with = a verify, it looks like it completes the verification bit but then fails = to write to the plist file. 

With the increased debugging, I see this in the macOS = Comsole:

default 14:12:26.297714+0100 = kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13 default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80

So it looks as if it is a = permission issue. Maybe the mcOS SMB client has started using some bit = of the protocol that Samba on FreeBSD doesn=E2=80=99t support for = ACLs?

David

On 6 Sep 2024, at 22:48, Craig = Leres <leres@freebsd.org> = wrote:

=EF=BB=BFLast year you guys helped me get this to work = with samba416. I recently tried to upgrade to samba419 and so far I'm = unsuccessful. The error is "The backup disk image could not be created" = and I'm running 14.1.

I'm using the = same port build options with 4.16 and = 4.19:

=    FAM
=    PYTHON3
=    QUOTAS
=    SYSLOG
=    UTMP
=    GSSAPI_BUILTIN
=    AVAHI
=    FRUIT

Having learned = my lesson when I upgraded from 4.13 to 4.16, I removed the old backups = from the zfs volume on the server before starting. I've also learned the = rule that you need to delete and reattach the share on the mac side when = you change the samba config.

Appended = is the config that works with 4.16 (but not = 4.19)

      =  Craig

[global]
=    workgroup =3D XYZ
=    security =3D user
=    netbios name =3D red
=    server string =3D red.example.net
=    hostname lookups =3D no
=    server role =3D standalone = server

   interfaces =3D = ixl0 lo0
   bind interfaces only =3D = yes

   load printers =3D = no
   show add printer wizard =3D = no
   time server =3D = yes
   use mmap =3D = yes

   dos charset =3D = 850
   unix charset =3D = UTF-8
   mangled names =3D = no

   #log level =3D = 3
   #log file =3D = /tmp/samba.log
   vfs objects =3D catia = fruit streams_xattr zfsacl

=    fruit:model =3D MacSamba
=    fruit:resource =3D file
=    fruit:metadata =3D netatalk
=    fruit:nfs_aces =3D yes
=    fruit:copyfile =3D no
=    fruit:aapl =3D yes
=    fruit:zero_file_id =3D = yes

   inherit = permissions =3D = yes


[Time = Machine]
   path =3D = /backups/mini
   read only =3D = no
   guest ok =3D no
=    writeable =3D yes
=    browseable =3D yes
=    fruit:resource =3D file
=    fruit:time machine =3D yes
=    valid users =3D backup-mini
=    max disk size 512G

=    hosts allow =3D = 10.0.0.19



= --Apple-Mail=_77A5D516-896F-451A-85CC-D471D0F0682F-- From nobody Sun Sep 8 12:29:04 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 4X1q5h4l2Dz5TjXF for ; Sun, 08 Sep 2024 12:29:12 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1q5h23n9z53lX; Sun, 8 Sep 2024 12:29:12 +0000 (UTC) (envelope-from dimitry@andric.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (longrow.wg.andric.com [10.69.1.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 194194B57; Sun, 08 Sep 2024 14:29:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andric.com; s=201904; t=1725798545; bh=t/fCk8iw6MWS9A5LjMIZ+NK8ru8WOYVtyj+eF2gRVeA=; h=From:Message-Id:Subject:Date:In-Reply-To:Cc:To:References:From; b=Uwhs6E9dudO5gmgP8BOANOFXF33uzXOTEe9/K3lzNuhVPAlzV6NKieWwFB4g/3o0e KQw2kpl110c/wPuZMYYNPG7pDxcdhVghwsVGkQ/77TDnN9nymNz142+v+JVqlt5QEY q5B/fnpTDYFUBejPUR3jiu77Z59mG9ABfrz7PUoZt51H0VmKHHQChmM8bfFpifRMZU K8/NPZDnzAJEO5bgbrwGsBMSYmzITpC19pDXrv2q/FYsesW6tLE8IYnq4EHGQ8LF/m Nko+ph7BSkie12bPHPojryy/ElI4kz2oUS+F/Tiv36aFwtqd6hMSWSsE03w0KipT4j jG7M0wyPel4Yw== From: Dimitry Andric Message-Id: <63540459-7D2E-4B70-962D-957550D294A3@andric.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE" 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 (Mac OS X Mail 16.0 \(3731.700.6.1.2\)) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 14:29:04 +0200 In-Reply-To: <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> Cc: Craig Leres , FreeBSD Hackers To: David Chisnall References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> X-Mailer: Apple Mail (2.3731.700.6.1.2) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12859, ipnet:87.251.32.0/19, country:NL] X-Rspamd-Queue-Id: 4X1q5h23n9z53lX --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have never needed to explicitly set fruit:posix_rename, my Time = Machine backups work completely fine without it (maybe it defaults to on = now?). I have been using Samba 4.19 since the port came out too. The only problem I encountered was with samba416 and fruit:zero_file_id, = which severely borked TM shares, see = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269883 for the gory = details. Since I don't have access to a Sonoma Mac on my network, I have used = Windows instead to make a bunch of subdirectories in a Samba share with = fruit:time machine enabled, but I can rename them at any level without = issue. -Dimitry > On 8 Sep 2024, at 14:10, David Chisnall wrote: >=20 > I have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360= to track this. >=20 > Reverting to samba416, I can back up in a new share, but I cannot back = up to the share that had my existing backups in it. This may be a = permissions issue or some problem withe metadata getting out of sync: = moving the backupbundle from the old share to the new one does not fix = it. Once I have a new complete backup, I will try comparing the = metadata and seeing what the differences are. >=20 > So far, the main difference appears to be that the new backup creates = a disk image bundle with 500 MiB bands whereas the old one was using 8 = MiB bands. This change is presumably because APFS, unlike HFS+, = supports holes in files, but I wonder if there=E2=80=99s a problem with = Samba and very large directories? There were 47,486 bands in the old = disk image. >=20 > David >=20 >> On 8 Sep 2024, at 12:48, David Chisnall wrote: >>=20 >> A little bit more debugging, and a working hypothesis: >>=20 >> I have tried creating a new Time Machine share (empty directory) and = pointing the Mac at it. On the first backup, it creates a = `.com.apple.timemachine.supported-{uuid}` file and a = `{uuid}-{date}.sparsebundle` directory. It appears to create a valid = sparse bundle, but other posts suggest that it then renames this to = `{computername}.backupbundle`. There is a Samba setting: = `fruit:posix_rename` that is supposed to control this. It appears to = fail at the point where it should do this rename. =20 >>=20 >> If I mount the same share, I can reproduce this: >>=20 >> $ mkdir tmp >> $ touch tmp/foo >> $ mv tmp fmp >> mv: rename tmp to fmp: Operation not supported >>=20 >> So it appears that something in the FreeBSD port of Samba has broken = the ability to rename directories. =20 >>=20 >> This appears to be recent breakage. Reverying to net/samba416 fixes = this bit, at least, and I can now back up to a pristine share. >>=20 >> David >>=20 >>> On 7 Sep 2024, at 08:28, David Chisnall = wrote: >>>=20 >>> I believe this was broken by a macOS update around February. I=E2=80=99= ve been trying to debug for a while. I=E2=80=99ve opened an Apple issue = (FB14500950, for any Apple folks) but it shows up as few people = reporting it. I posted on Mastodon and several people reported that Time = Machine is broken and recommended Carbon Copy Cloner as an alternative. = I would like to see it fixed, but it probably needs some more debugging = by Apple folks.=20 >>>=20 >>> It stopped working for me with no changes on the server and I can = reproduce the failures on two different Macs. >>>=20 >>> Things I have tried: >>>=20 >>> - Upgrading Samba from 4.16 to 4.19 >>> - Upgrading FreeBSD from 13.x to 14.1 >>> - Setting the SMB timeout sysctls to larger values on macOS. >>> - Turning up the SMB debug sysctls on macOS to see if there=E2=80=99s= more info >>> - Turning up the Samba logging level. >>> - Verifying the backups >>> - Watching smbinfo the server. >>> - Updating macOS to the latest version >>> - Connecting to the server with Finder and checking I can access = files on the shares and that they have the right permissions. >>>=20 >>> Samba doesn=E2=80=99t report any errors (I don=E2=80=99t know if = there=E2=80=99s a way to force Samba to report permission-denied = things). >>>=20 >>> It appears that the Mac acquires a load of read-only locks and so = does a lot of reads, but for some reason it appears to fail the first = write. Even with a verify, it looks like it completes the verification = bit but then fails to write to the plist file.=20 >>>=20 >>> With the increased debugging, I see this in the macOS Comsole: >>>=20 >>> default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 >>> default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 >>> default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 >>> default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 >>> default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs >>> default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.542682+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543657+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543697+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543730+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>>=20 >>> So it looks as if it is a permission issue. Maybe the mcOS SMB = client has started using some bit of the protocol that Samba on FreeBSD = doesn=E2=80=99t support for ACLs? >>>=20 >>> David >>>=20 >>>> On 6 Sep 2024, at 22:48, Craig Leres wrote: >>>>=20 >>>> =EF=BB=BFLast year you guys helped me get this to work with = samba416. I recently tried to upgrade to samba419 and so far I'm = unsuccessful. The error is "The backup disk image could not be created" = and I'm running 14.1. >>>>=20 >>>> I'm using the same port build options with 4.16 and 4.19: >>>>=20 >>>> FAM >>>> PYTHON3 >>>> QUOTAS >>>> SYSLOG >>>> UTMP >>>> GSSAPI_BUILTIN >>>> AVAHI >>>> FRUIT >>>>=20 >>>> Having learned my lesson when I upgraded from 4.13 to 4.16, I = removed the old backups from the zfs volume on the server before = starting. I've also learned the rule that you need to delete and = reattach the share on the mac side when you change the samba config. >>>>=20 >>>> Appended is the config that works with 4.16 (but not 4.19) >>>>=20 >>>> Craig >>>>=20 >>>> [global] >>>> workgroup =3D XYZ >>>> security =3D user >>>> netbios name =3D red >>>> server string =3D red.example.net >>>> hostname lookups =3D no >>>> server role =3D standalone server >>>>=20 >>>> interfaces =3D ixl0 lo0 >>>> bind interfaces only =3D yes >>>>=20 >>>> load printers =3D no >>>> show add printer wizard =3D no >>>> time server =3D yes >>>> use mmap =3D yes >>>>=20 >>>> dos charset =3D 850 >>>> unix charset =3D UTF-8 >>>> mangled names =3D no >>>>=20 >>>> #log level =3D 3 >>>> #log file =3D /tmp/samba.log >>>> vfs objects =3D catia fruit streams_xattr zfsacl >>>>=20 >>>> fruit:model =3D MacSamba >>>> fruit:resource =3D file >>>> fruit:metadata =3D netatalk >>>> fruit:nfs_aces =3D yes >>>> fruit:copyfile =3D no >>>> fruit:aapl =3D yes >>>> fruit:zero_file_id =3D yes >>>>=20 >>>> inherit permissions =3D yes >>>>=20 >>>>=20 >>>> [Time Machine] >>>> path =3D /backups/mini >>>> read only =3D no >>>> guest ok =3D no >>>> writeable =3D yes >>>> browseable =3D yes >>>> fruit:resource =3D file >>>> fruit:time machine =3D yes >>>> valid users =3D backup-mini >>>> max disk size 512G >>>>=20 >>>> hosts allow =3D 10.0.0.19 >>>>=20 >>=20 >=20 --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have never = needed to explicitly set fruit:posix_rename, my Time Machine backups = work completely fine without it (maybe it defaults to on now?). I have = been using Samba 4.19 since the port came out = too.

The only problem I encountered was with samba416 = and fruit:zero_file_id, which severely borked TM shares, see https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269883 for the = gory details.

Since I don't have access to a = Sonoma Mac on my network, I have used Windows instead to make a bunch of = subdirectories in a Samba share with fruit:time machine enabled, but I = can rename them at any level without = issue.

-Dimitry

On 8 Sep 2024, at 14:10, David Chisnall = <theraven@FreeBSD.org> wrote:

I = have opened https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360 to track = this.

Reverting to samba416, I can back up in a new = share, but I cannot back up to the share that had my existing backups in = it.  This may be a permissions issue or some problem withe metadata = getting out of sync: moving the backupbundle from the old share to the = new one does not fix it.  Once I have a new complete backup, I will = try comparing the metadata and seeing what the differences = are.

So far, the main difference appears to be = that the new backup creates a disk image bundle with 500 MiB bands = whereas the old one was using 8 MiB bands.  This change is = presumably because APFS, unlike HFS+, supports holes in files, but I = wonder if there=E2=80=99s a problem with Samba and very large = directories?  There were 47,486 bands in the old disk = image.

David

On 8 Sep 2024, at 12:48, David Chisnall = <theraven@FreeBSD.org> wrote:

A = little bit more debugging, and a working = hypothesis:

I have tried creating a new Time Machine = share (empty directory) and pointing the Mac at it.  On the first = backup, it creates a `.com.apple.timemachine.supported-{uuid}` file and = a `{uuid}-{date}.sparsebundle` directory.  It appears to create a = valid sparse bundle, but other posts suggest that it then renames this = to `{computername}.backupbundle`.  There is a Samba setting: = `fruit:posix_rename` that is supposed to control this.  It appears = to fail at the point where it should do this rename. =  

If I mount the same share, I can = reproduce this:

$ mkdir tmp
$ = touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: = Operation not supported

So it appears = that something in the FreeBSD port of Samba has broken the ability to = rename directories.  

This appears to be = recent breakage.  Reverying to net/samba416 fixes this bit, at = least, and I can now back up to a pristine = share.

David

On 7 Sep 2024, at 08:28, David Chisnall = <theraven@FreeBSD.org> wrote:

I believe this was broken by a macOS = update around February. I=E2=80=99ve been trying to debug for a while. = I=E2=80=99ve opened an Apple issue (FB14500950, for any Apple folks) but = it shows up as few people reporting it. I posted on Mastodon and several = people reported that Time Machine is broken and recommended Carbon Copy = Cloner as an alternative. I would like to see it fixed, but it probably = needs some more debugging by Apple folks. 

It stopped working for me with no = changes on the server and I can reproduce the failures on two different = Macs.

Things I have = tried:

 - = Upgrading Samba from 4.16 to 4.19
 - = Upgrading FreeBSD from 13.x to 14.1
 - = Setting the SMB timeout sysctls to larger values on macOS.
 - Turning up the SMB debug sysctls on macOS to see if = there=E2=80=99s more info
 - Turning up the = Samba logging level.
 - Verifying the = backups
 - Watching smbinfo the = server.
 - Updating macOS to the latest = version
 - Connecting to the server with = Finder and checking I can access files on the shares and that they have = the right permissions.

Samba doesn=E2=80=99t report any errors (I don=E2=80=99t = know if there=E2=80=99s a way to force Samba to report permission-denied = things).

It appears = that the Mac acquires a load of read-only locks and so does a lot of = reads, but for some reason it appears to fail the first write. Even with = a verify, it looks like it completes the verification bit but then fails = to write to the plist file. 

With the increased debugging, I see this in the macOS = Comsole:

default 14:12:26.297714+0100 = kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13 default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: = smb2fs_smb_ntcreatex failed 13 default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: = smb2_smb_query_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS = initWithFileDescriptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80

So it looks as if it is a = permission issue. Maybe the mcOS SMB client has started using some bit = of the protocol that Samba on FreeBSD doesn=E2=80=99t support for = ACLs?

David

On 6 Sep 2024, at 22:48, Craig = Leres <leres@freebsd.org> = wrote:

=EF=BB=BFLast year you guys helped me get this to work = with samba416. I recently tried to upgrade to samba419 and so far I'm = unsuccessful. The error is "The backup disk image could not be created" = and I'm running 14.1.

I'm using the = same port build options with 4.16 and = 4.19:

=    FAM
=    PYTHON3
=    QUOTAS
=    SYSLOG
=    UTMP
=    GSSAPI_BUILTIN
=    AVAHI
=    FRUIT

Having learned = my lesson when I upgraded from 4.13 to 4.16, I removed the old backups = from the zfs volume on the server before starting. I've also learned the = rule that you need to delete and reattach the share on the mac side when = you change the samba config.

Appended = is the config that works with 4.16 (but not = 4.19)

      =  Craig

[global]
=    workgroup =3D XYZ
=    security =3D user
=    netbios name =3D red
=    server string =3D red.example.net
=    hostname lookups =3D no
=    server role =3D standalone = server

   interfaces =3D = ixl0 lo0
   bind interfaces only =3D = yes

   load printers =3D = no
   show add printer wizard =3D = no
   time server =3D = yes
   use mmap =3D = yes

   dos charset =3D = 850
   unix charset =3D = UTF-8
   mangled names =3D = no

   #log level =3D = 3
   #log file =3D = /tmp/samba.log
   vfs objects =3D catia = fruit streams_xattr zfsacl

=    fruit:model =3D MacSamba
=    fruit:resource =3D file
=    fruit:metadata =3D netatalk
=    fruit:nfs_aces =3D yes
=    fruit:copyfile =3D no
=    fruit:aapl =3D yes
=    fruit:zero_file_id =3D = yes

   inherit = permissions =3D = yes


[Time = Machine]
   path =3D = /backups/mini
   read only =3D = no
   guest ok =3D no
=    writeable =3D yes
=    browseable =3D yes
=    fruit:resource =3D file
=    fruit:time machine =3D yes
=    valid users =3D backup-mini
=    max disk size 512G

=    hosts allow =3D = 10.0.0.19




= --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE-- From nobody Sun Sep 8 13:02:30 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 4X1qrH325hz5Tp5P for ; Sun, 08 Sep 2024 13:02:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1qrH0wWHz58pC for ; Sun, 8 Sep 2024 13:02:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 008578928E; Sun, 08 Sep 2024 13:02:30 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 488D2UvB069580; Sun, 8 Sep 2024 13:02:30 GMT (envelope-from phk) Message-Id: <202409081302.488D2UvB069580@critter.freebsd.dk> To: Alexander Leidinger cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@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 Content-Type: text/plain; charset="us-ascii" Content-ID: <69578.1725800550.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 08 Sep 2024 13:02:30 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X1qrH0wWHz58pC -------- Alexander Leidinger writes: I'm only going to answer two bits from your email: > > 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). Nope. The only reason the Rust advocates need to bring this up is /precisely/ because that is not the case. If it were, they would just have added ports. > 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. Beware of selection bias. "Somebody who compiles from src" is almost the literal definition of "comm= itter". In terms of all the FreeBSD running hardware out there, not even one percent of one percent of the machines compile from src. (Hint: Consumer electronics and server farms running FreeBSD) Poul-Henning -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Sun Sep 8 13:50:56 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 4X1rwG2WfHz5TwJ0 for ; Sun, 08 Sep 2024 13:51:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1rwF6fJ5z43Xt for ; Sun, 8 Sep 2024 13:51:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-20551eeba95so31458675ad.2 for ; Sun, 08 Sep 2024 06:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725803468; x=1726408268; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jqyZUrnH+1fG/GWLyEuvuOdaB2HskGsYRlp0PbuwTrE=; b=TWkgvuMJZQ8AxtQl7HUU7E37lzVKZYz58Hk+pX21xu1NkUMupfr0UGoo02JQnxVFtw UfDfdmACpfkHl4sIAj88Zcy6J794wY52vor/bMorxnLr9OPlUB/GB6Ur9KSsfRvE9l5O uM+QgTKe4uiNyRLh1Tq65oyi79HYe8Apm+1lzgR3UPIBzblePnBSfeggfopQ09EsFUSz MD1JyAsLOmSwVTh21VePLalxlHTPVfbgcF2YmP0tBVLmtz9VfvHYHWmrHFMy9rS4QrXL XlpSe1K4ePIQUY4fKKg+/MtSCO8mPFHHgiEvCkQ7XwC5jD2bT7BDHvrkPpLOfUj/b7hW 9twA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725803468; x=1726408268; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jqyZUrnH+1fG/GWLyEuvuOdaB2HskGsYRlp0PbuwTrE=; b=Ve0DzaoLscbmKy0N7dDKmDFRIz14mb9z7/H0kzdwVwVQ4C7odbAbl3vM2YbkKu3v1k TS732ZxJwcIsntcnGKiUTSX5tiO6+efYsyfHHVvjaRdDTOoFdPPSxWclgHazjzChwlgT zLjIyk8R+TzYJIoKk7QZsIZdx2OtPoV5nGstctaQSn+9TRkR+IrglBlUHogfZ1q7RpAK 3yRS4dRSy/lG+CxJHM2BfMBCx2XYlTaZ+3g67Y1nkebzNVjJAR17rXUZc7LS+rwKPXwh qdqDa/ZPK+DZLblMJCPZSBVuU7/YApvCsifgaCXL2BL7A0X6EimN0CGvZbB/f87BVu57 ruww== X-Forwarded-Encrypted: i=1; AJvYcCWSy7lcHhLrie6L2WrWxVEGmh/lXwXCaf2Bqqx12sFJf/v0UahQLC/SeGPHALZvNsRfcMHYuDe4g+cde8vxu5c=@freebsd.org X-Gm-Message-State: AOJu0YzpKhOn97v3p26Obw0tqESDVHlDF/V+KzQ+HNbFeZnZZHgfEVZy A+mI0ep6snE/JlZ0+1YRilOy8CLxK/26G5LMa1rQEaTIduh/E9uJFlodkMwv5MLSddIUTTle697 P25tDlaNOzReDnXlszSrcZ1Wthxa7fGwn6N8KYg== X-Google-Smtp-Source: AGHT+IGKuaEAFQJoUX2bU026MZrcr4QFzdL2OAe5AlSdXC3bGEk94KX2i6+g5Qz3ah4Em+7FdIUX2YtpsnQW64MpVR4= X-Received: by 2002:a17:902:f60d:b0:205:6a4c:9a20 with SMTP id d9443c01a7336-206f053ade0mr93554425ad.34.1725803468395; Sun, 08 Sep 2024 06:51:08 -0700 (PDT) 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 References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 8 Sep 2024 07:50:56 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Kristof Provost Cc: David Chisnall , Poul-Henning Kamp , Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000afb91b06219bee0d" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X1rwF6fJ5z43Xt --000000000000afb91b06219bee0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Kristof On Sun, Sep 8, 2024 at 1:44=E2=80=AFAM Kristof Provost wro= te: > On 6 Sep 2024, at 9:41, David Chisnall wrote: > > The strategy document that I coauthored at Microsoft recommended the > following: > > - C++ conforming to the Core Guidelines and with static analysis for > existing C/C++ projects with the C parts incrementally migrated to C++. > > While I=E2=80=99d be interested in seeing Rust demonstrated there are cle= arly > still some practical issues to work out before we can, even in user space= . > > So, at the risk of derailing the Rust conversation, I want to ask about > C++. > > We already ship user space C++ code, what=E2=80=99s stopping us from doin= g so for > kernel code? > If we can get some of the benefit of a more modern language with much les= s > effort would that be a worthwhile step? RAII would not *always* make > reasoning about locks easier, but it would in at least 95% of cases. > > What would we need to do to be able to use C++ in the kernel? > So there's four big issues with C++ in the kernel, all surmountable if we wanted. There's the low-level allocation issues. Right now we know what memory is used by what because we have malloc enhanced to track this (oversimplifying a lot I know). So we'd need some framework to make it easy to have 'custom allocators' that could track it as well. At a bare minimum, we need the runtime support for new and delete... Next, there's all the other run-time support that's provided by compiler-rt= . Next, there's the issues of exceptions. They are quite useful for RAII (since you know dtors will get run when an error happens), and there'd need to be some sane plan for these (or we'd have to forego them). Finally, there's getting the subset of the standard library that's useful into the kernel. There's a lot of templates for facilitating RAII that are needed, for example, and some subset of STL, etc. Once you have those 'table stakes' issues out of the way, you'll need to see how it performs, and work out a few dozen logistical issues surrounding what compiler flags to use, what language features to enable/disable, how to optimize and what set of warnings are sensible. You could start using C++ with just the second of these items. Warner --000000000000afb91b06219bee0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Kristof

On Sun, Sep 8, 2024 at 1:4= 4=E2=80=AFAM Kristof Provost <kp@freeb= sd.org> wrote:

On 6 Sep 2024, at 9:41, David Chisnall wrote:

The strategy document that I coauthored at Microsof= t recommended the following:

- C++ conforming to the Core Guidelines and with static an= alysis for existing C/C++ projects with the C parts incrementally migrated = to C++.

While I=E2=80=99d be interested in seeing Rust demonstrated= there are clearly still some practical issues to work out before we can, e= ven in user space.

So, at the risk of derailing the Rust conversation, I want = to ask about C++.

We already ship user space C++ code, what=E2=80=99s stoppin= g us from doing so for kernel code?
If we can get some of the benefit of a more modern language with much less = effort would that be a worthwhile step? RAII would not always make= reasoning about locks easier, but it would in at least 95% of cases.

What would we need to do to be able to use C++ in the kerne= l?


So there's fou= r big issues with C++ in the kernel, all surmountable if we wanted.

There's the low-level allocation issues. Right now we= know what memory is used by what because we have malloc enhanced to track = this (oversimplifying a lot I know). So we'd need some framework to mak= e it easy to have 'custom allocators' that could track it as well. = At a bare minimum, we need the runtime support for new and delete...
<= div>
Next, there's all the other run-time support that= 9;s provided by compiler-rt.

Next, there's the= issues of exceptions. They are quite useful for RAII (since you know dtors= will get run when an error happens), and there'd need to be some sane = plan for these (or we'd have to forego them).

= Finally, there's getting the subset of the standard library that's = useful into the kernel. There's a lot of templates for facilitating RAI= I that are needed, for example, and some subset of STL, etc.

=
Once you have those 'table stakes' issues out of the way= , you'll need to see how it performs, and work out a few dozen logistic= al issues surrounding what compiler flags to use, what language features to= enable/disable, how to optimize and what set of warnings are sensible.

You could start using C++ with just the second of the= se items.

Warner
--000000000000afb91b06219bee0d-- From nobody Sun Sep 8 15:05:00 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 4X1tYj38k3z5V7Xm for ; Sun, 08 Sep 2024 15:05:13 +0000 (UTC) (envelope-from theraven@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 4X1tYj2bGnz4Ckc; Sun, 8 Sep 2024 15:05:13 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725807913; 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=ykRXOAd7nXvIkwG6fZQJ3jE1H9nQvPO8slsqpXd9+vU=; b=PprwZj0AKPDFrV7TmiQ3/f5ZAUtFGYcevWm4xWkYlRvGa97IYV1oVaUico5bkrw8TrPIG0 hq+2+edrZQkLGt8vTKJjxDZVh4VjCTdPnU5rxnxHh22R5EXS8+m/pYg255JkITEtTj2/UC oKyi+CergbYmRxvX6Q2V6NMFTBBavzzqcUuEReHUFYBw3F234phkNJRu4ZO1zI8oWRj2Rx /WKv96igp95076UZuOUvJsQm3EnoBYy5gUcT2H/NwDE+Z1JwlOqWA3sVDw8TZoctQ9kiMW zaLMgl8VvlgDoJ5Ti5q4YwsXUKefVr1tDy+5YBq1zsBLKuteRqHxUSdRH+YS6A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725807913; a=rsa-sha256; cv=none; b=JtWsmeY/m4eEHkwFwl0SsMQfTq/J9UAMmM2RM4dKmqgZNqo1FXnsl87B99QvUB4iu+rhiI DSJAe8bKvXKT4Ynh9742Vh3V0m1el0ywCoblemhBuE2R5Wo22coYpvlfdHd2gXBXFBi4ei +OlAnoZSt/h3en2h/xZGA+wtt6Nhd5Zcl9wmGs3r/zUryELTIMNiXP6i688n5kAfKEuH6r gkmgH0vPBmqetHvFjYV5yzoREdC2Ccf1YM431Rdgj4S3xHIB9Fg69we5madfY4xMOXvPIe 6pINisclbrSHZEQO3+CIN3U6FGQSxcbDU4xMsVOxPzKJi+IBauWW/rCO+Noisg== 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=1725807913; 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=ykRXOAd7nXvIkwG6fZQJ3jE1H9nQvPO8slsqpXd9+vU=; b=YiPw9y4UmU/2mKnmkgmkcRNSMTTtkY839nQEcMgAK9z5ouXoATUyjAoyFbozYUsJKaIxkr J4oFMtj0oxC6Z2+/TbSa9jAXKyPcHJ1sLD/TC2UdseNXMKwBG4bAMLHiuLnOPi9P4Sm6zK LiWnawFzkRGpbhCC+3vmSkC34+9wtVH7N0vWcvyRPqpRzia8k9qmE9QpFrCnrun7tyNNVH DZ73kxwrDJAPNPJkVFEC4kaZff/FkLpR4CS+R7BLrE1eVu0cF2VANAuWkgnIJ0Qztiv9rC wY1WFK/BMmzAaQ/QBZnk0IbUO49MTxD1FKhCJhfPjW2Ckv1Ph71ropJ52qVHNA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1tYj206CzSNN; Sun, 8 Sep 2024 15:05:13 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7DCF36561; Sun, 08 Sep 2024 16:05:11 +0100 (BST) From: David Chisnall Message-Id: <0BC57127-5CF9-45C5-9BE6-7E21D2313291@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_60EE3B51-FED3-4D06-9928-5631210681CB" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) Date: Sun, 8 Sep 2024 16:05:00 +0100 In-Reply-To: Cc: Kristof Provost , Poul-Henning Kamp , Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org To: Warner Losh References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_60EE3B51-FED3-4D06-9928-5631210681CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 8 Sep 2024, at 14:50, Warner Losh wrote: >=20 > So there's four big issues with C++ in the kernel, all surmountable if = we wanted. There are two missing from your list, which I encountered when I wrote a = kernel module for FreeBSD in C++ a few years ago: C++ relies on COMDATs quite a lot. Each inline function and each = function that=E2=80=99s instantiated as a template is a separate section = with some flags indicating that the linker / loader should keep one and = discard the rest. If you have a single C++ module, this is fine, but for = two it=E2=80=99s harder. I did a small =E2=80=98libkxx=E2=80=99 module = that provided a subset of libc++ for use by different modules, but the = kernel loader code didn=E2=80=99t have enough comments for me to = understand how to fix it. I would be tempted to approach this with a = userspace tool that runs over a set of kernel modules and pulls out = duplicated COMDATs into separate modules that other things can depend = on. Alternatively, the kernel loader could be modified to load only = referenced COMDATs, reference count them, and not load unused things = from each kernel module. The latter is a cleaner approach but is more = work. Second, between 11 and 12, someone decided to replaces a load of static = inline functions in kernel headers with macros. These conflict a lot. > There's the low-level allocation issues. Right now we know what memory = is used by what because we have malloc enhanced to track this = (oversimplifying a lot I know). So we'd need some framework to make it = easy to have 'custom allocators' that could track it as well. At a bare = minimum, we need the runtime support for new and delete... This is not technically required, but it is a good idea to think about = what the right strategy is. A C++ class can implement its own `operator = new` and `operator delete` wrapping `malloc(9)` and then subclasses will = allocate with that. Similarly, things like `std::unique_ptr` can take = an explicit deleter. This can be a bit clunky and it=E2=80=99s probably a good idea to have = some sensible defaults. > Next, there's all the other run-time support that's provided by = compiler-rt. Nothing in compiler-rt is needed for C++ except the unwinder if you want = exceptions (no one else except NT uses exceptions in a kernel). The one = bit of libcxxrt that you would probably want is the support for guard = variables, which would need modifying to use kernel locks. This is = fairly small, I wrote a custom one for CHERIoT RTOS which uses our futex = APIs. > Next, there's the issues of exceptions. They are quite useful for RAII = (since you know dtors will get run when an error happens), and there'd = need to be some sane plan for these (or we'd have to forego them). Most kernels disable exceptions. You absolutely do not want = Itanium-style exceptions in a kernel because they need to allocate to = throw exceptions and so you would only be able to throw from places = where allocation is safe. Given that the most common place you=E2=80=99d = want to throw an exception (if you had them) is if `malloc` with = `M_NOWAIT` failed, this could be a problem. NT uses SEH exceptions, which allocate all of the state on the stack and = then run funclets for cleanup. It would be possible to support this in = the kernel (the relevant patents expired over ten years ago), but a = non-trivial amount of work. If someone wanted to do the work, it would = be great: SEH is one of the very few things I really liked about the NT = kernel. > Finally, there's getting the subset of the standard library that's = useful into the kernel. There's a lot of templates for facilitating RAII = that are needed, for example, and some subset of STL, etc. You don=E2=80=99t need templates for RAII, RAII just depends on = destructors. Templates are useful, but largely orthogonal. I=E2=80=99d = personally recommend against using much of the standard library in the = kernel because it does not have good ways of handling allocation failure = without exceptions. The C++ standard defines a Freestanding profile = (similar to C) that includes things like the type traits that are useful = for compile-time metaprogramming. There are a few bits you might want = to pull in but a lot more that you=E2=80=99d want to avoid (I actually = have iostream working with the kernel=E2=80=99s printf family, but it = was a terrible idea and no one should ever use that code). For example, `std::shared_ptr` is probably not a good idea (it allocates = a separate control block to hold the ref count), but something that = wraps things that are intrusively reference counted with `refcount(9)` = in smart pointers would be valuable. Using member pointers, it=E2=80=99s = easy to build a smart-pointer template that takes a C type that contains = a refcount and a pointer to the field and automatically manipulates the = reference count when you copy the pointer. > Once you have those 'table stakes' issues out of the way, you'll need = to see how it performs, and work out a few dozen logistical issues = surrounding what compiler flags to use, what language features to = enable/disable, how to optimize and what set of warnings are sensible. -fno-exceptions and -fno-rtti is what most peopls use for kernel = programming (there are a few dozen kernels written in C++, it=E2=80=99s = not like we=E2=80=99d be the first to try). > You could start using C++ with just the second of these items. You can use it within a single kernel module now, as long as you resolve = COMDATs prior to linking and #undef a bunch of things. I was doing so = five years ago. The build system actually supports it already, though = possibly not deliberately. David --Apple-Mail=_60EE3B51-FED3-4D06-9928-5631210681CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 8 Sep 2024, = at 14:50, Warner Losh <imp@bsdimp.com> wrote:

So there's four = big issues with C++ in the kernel, all surmountable if we = wanted.

There = are two missing from your list, which I encountered when I wrote a = kernel module for FreeBSD in C++ a few years = ago:

C++ relies on COMDATs quite a lot. =  Each inline function and each function that=E2=80=99s instantiated = as a template is a separate section with some flags indicating that the = linker / loader should keep one and discard the rest. If you have a = single C++ module, this is fine, but for two it=E2=80=99s harder. =  I did a small =E2=80=98libkxx=E2=80=99 module that provided a = subset of libc++ for use by different modules, but the kernel loader = code didn=E2=80=99t have enough comments for me to understand how to fix = it. I would be tempted to approach this with a userspace tool that runs = over a set of kernel modules and pulls out duplicated COMDATs into = separate modules that other things can depend on.  Alternatively, = the kernel loader could be modified to load only referenced COMDATs, = reference count them, and not load unused things from each kernel = module.  The latter is a cleaner approach but is more = work.

Second, between 11 and 12, someone = decided to replaces a load of static inline functions in kernel headers = with macros.  These conflict a lot.

There's the = low-level allocation issues. Right now we know what memory is used by = what because we have malloc enhanced to track this (oversimplifying a = lot I know). So we'd need some framework to make it easy to have 'custom = allocators' that could track it as well. At a bare minimum, we need the = runtime support for new and = delete...

This = is not technically required, but it is a good idea to think about what = the right strategy is.  A C++ class can implement its own `operator = new` and `operator delete` wrapping `malloc(9)` and then subclasses will = allocate with that.  Similarly, things like `std::unique_ptr` can = take an explicit deleter.

This can be a bit = clunky and it=E2=80=99s probably a good idea to have some sensible = defaults.

Next, there's = all the other run-time support that's provided by = compiler-rt.

Nothi= ng in compiler-rt is needed for C++ except the unwinder if you want = exceptions (no one else except NT uses exceptions in a kernel). =  The one bit of libcxxrt that you would probably want is the = support for guard variables, which would need modifying to use kernel = locks.  This is fairly small, I wrote a custom one for CHERIoT RTOS = which uses our futex APIs.

Next, there's = the issues of exceptions. They are quite useful for RAII (since you know = dtors will get run when an error happens), and there'd need to be some = sane plan for these (or we'd have to forego = them).

Most = kernels disable exceptions.  You absolutely do not want = Itanium-style exceptions in a kernel because they need to allocate to = throw exceptions and so you would only be able to throw from places = where allocation is safe.  Given that the most common place you=E2=80= =99d want to throw an exception (if you had them) is if `malloc` with = `M_NOWAIT` failed, this could be a problem.

NT = uses SEH exceptions, which allocate all of the state on the stack and = then run funclets for cleanup.  It would be possible to support = this in the kernel (the relevant patents expired over ten years ago), = but a non-trivial amount of work.  If someone wanted to do the = work, it would be great: SEH is one of the very few things I really = liked about the NT kernel.

Finally, there's = getting the subset of the standard library that's useful into the = kernel. There's a lot of templates for facilitating RAII that are = needed, for example, and some subset of STL, = etc.

You don=E2=80= =99t need templates for RAII, RAII just depends on destructors. =  Templates are useful, but largely orthogonal.  I=E2=80=99d = personally recommend against using much of the standard library in the = kernel because it does not have good ways of handling allocation failure = without exceptions.  The C++ standard defines a Freestanding = profile (similar to C) that includes things like the type traits that = are useful for compile-time metaprogramming.  There are a few bits = you might want to pull in but a lot more that you=E2=80=99d want to = avoid (I actually have iostream working with the kernel=E2=80=99s printf = family, but it was a terrible idea and no one should ever use that = code).

For example, `std::shared_ptr` is = probably not a good idea (it allocates a separate control block to hold = the ref count), but something that wraps things that are intrusively = reference counted with `refcount(9)` in smart pointers would be = valuable.  Using member pointers, it=E2=80=99s easy to build a = smart-pointer template that takes a C type that contains a refcount and = a pointer to the field and automatically manipulates the reference count = when you copy the pointer.

Once you have = those 'table stakes' issues out of the way, you'll need to see how it = performs, and work out a few dozen logistical issues surrounding what = compiler flags to use, what language features to enable/disable, how to = optimize and what set of warnings are = sensible.

-fno-exc= eptions and -fno-rtti is what most peopls use for kernel programming = (there are a few dozen kernels written in C++, it=E2=80=99s not like = we=E2=80=99d be the first to try).

You could start = using C++ with just the second of these = items.

You can = use it within a single kernel module now, as long as you resolve COMDATs = prior to linking and #undef a bunch of things.  I was doing so five = years ago.  The build system actually supports it already, though = possibly not = deliberately.

David

= --Apple-Mail=_60EE3B51-FED3-4D06-9928-5631210681CB-- From nobody Sun Sep 8 16:16:51 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 4X1w8Y10w6z5VKH5 for ; Sun, 08 Sep 2024 16:17:01 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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 (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1w8X1mycz4N6H for ; Sun, 8 Sep 2024 16:16:59 +0000 (UTC) (envelope-from ml@netfence.it) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it Received: from [10.1.2.18] (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.18.1/8.17.2) with ESMTPSA id 488GGpcD047978 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 8 Sep 2024 18:16:52 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be [10.1.2.18] Message-ID: <4c0ea1fa-91ac-48ae-94ba-00d853fe1aa5@netfence.it> Date: Sun, 8 Sep 2024 18:16:51 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <0.2.0-final-1725702660.839-0xb11c62@qmda.emu.st> <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> From: Andrea Venturoli In-Reply-To: <54eef546-25c7-452a-ab52-7e39b133cdee@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4X1w8X1mycz4N6H On 9/7/24 20:18, Stefan Esser wrote: > Timemachine baclkups are working well using samba-3.16, but fail with > samba-3.19 (corrupting the backup!). You mean 4.16 and 4.19, right? From nobody Sun Sep 8 17:30:20 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 4X1xnR25Bsz5VWNh for ; Sun, 08 Sep 2024 17:30:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1xnQ4Pyfz4cy0 for ; Sun, 8 Sep 2024 17:30:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2d8abac30ddso2807753a91.0 for ; Sun, 08 Sep 2024 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725816633; x=1726421433; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U9qtbcijlQPfyEcM0bQRdj5Um+SYtT4jvwDcTIc/dEc=; b=Blnivwx5qehEVcFmok0eVgO+unMNOlU9NHaApSsFrqmPjTa1VGrPZCF090M2BwRuih oMLs/1QWiyAAye8/bGDagBmZtSzF/uHN1KT0kSNKTEEoUi8G4y8oRwyNISCwTRlDBKpr 0/KwzqhikSelQEEfdsy+rLIfct6hq5Ab/ER4r8FHup9kxUrT3S6CECdVvp41cDS03YG2 JRpJQW6XafF5dxeeaY/XJhwIIlxjYUdXhOEpnRCu+gXrKWrohbXmZCQ9+R1AvB1PjUf6 N82+1MS5ITVBse+oEL/t9WsGNbwjndk3SQl/TFNt00LNK1NlXOhHq/vmh8nQkv40fApk 8FuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725816633; x=1726421433; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U9qtbcijlQPfyEcM0bQRdj5Um+SYtT4jvwDcTIc/dEc=; b=I3wAyBUDPUXL5i2KDprszt0qCOJ1MrygES4utXfu4d1u77E59N1bmck+X+gtmza6hr ExBoYeEMfKLxkPkhFXVxvhPoDhoztNzk0P+1b6IXiQlqGUPo3PHtMa5akHBb1IQv59WZ Mwr2Xrb68zWsmskpDaAOV9L3oFvk1Bsdbz3mpS+NWkFSLg9ckJBW/X/stldgkMnvcpNB iWiwBHFEx9vEozksk31KtBnCPnCV178eaYB5I/Oz4PZvWBFcCsO/+8uQ+qO09i+3IbKA jcHUhMutce56PDafuR8DlVtEGMRED1JtCRQa3oF8O3sgTtyXOdXhkXEWsse69aKcPXzA sD8w== X-Forwarded-Encrypted: i=1; AJvYcCX3h8GDHSNGt9ZNpWVbcOYGGWYIDg6D+CA854cGXN0Jf4Siuc4RvtaSBDf2RevOAJ4bS9bPsTmL/29frOHTwlY=@freebsd.org X-Gm-Message-State: AOJu0YwHGrNzAd1MY6fYhm97RI/kEqx3uziH4ExwVBspTanrqCkgsFPu VQBII8rAjbwOzrfp/fQ40vE/7Y0pTBSgVWWW1EikKeaTG7WM0eU0FL1RnmykhaVCvoishAvWv/D dJTI6rJNVq/Ep8e+n5fgiHSKeGBTPOQihh+/tEw== X-Google-Smtp-Source: AGHT+IFP9nry+bhDM0b/iCCh4gvpGtTvMXFcyZ8ZG4YwPuqJqb+gJ7GTKWljtXLNhDrKjUly+3DwODek7byqhoJI0DI= X-Received: by 2002:a17:90a:a60d:b0:2d1:bf4b:4a6d with SMTP id 98e67ed59e1d1-2dad4def822mr8522356a91.1.1725816632728; Sun, 08 Sep 2024 10:30:32 -0700 (PDT) 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 References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> <0BC57127-5CF9-45C5-9BE6-7E21D2313291@FreeBSD.org> In-Reply-To: <0BC57127-5CF9-45C5-9BE6-7E21D2313291@FreeBSD.org> From: Warner Losh Date: Sun, 8 Sep 2024 11:30:20 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: David Chisnall Cc: Kristof Provost , Poul-Henning Kamp , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000578a3f06219eff80" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X1xnQ4Pyfz4cy0 --000000000000578a3f06219eff80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 8, 2024, 9:05=E2=80=AFAM David Chisnall = wrote: > On 8 Sep 2024, at 14:50, Warner Losh wrote: > > > So there's four big issues with C++ in the kernel, all surmountable if we > wanted. > > > There are two missing from your list, which I encountered when I wrote a > kernel module for FreeBSD in C++ a few years ago: > > C++ relies on COMDATs quite a lot. Each inline function and each functio= n > that=E2=80=99s instantiated as a template is a separate section with some= flags > indicating that the linker / loader should keep one and discard the rest. > If you have a single C++ module, this is fine, but for two it=E2=80=99s h= arder. I > did a small =E2=80=98libkxx=E2=80=99 module that provided a subset of lib= c++ for use by > different modules, but the kernel loader code didn=E2=80=99t have enough = comments > for me to understand how to fix it. I would be tempted to approach this > with a userspace tool that runs over a set of kernel modules and pulls ou= t > duplicated COMDATs into separate modules that other things can depend on. > Alternatively, the kernel loader could be modified to load only reference= d > COMDATs, reference count them, and not load unused things from each kerne= l > module. The latter is a cleaner approach but is more work. > > Second, between 11 and 12, someone decided to replaces a load of static > inline functions in kernel headers with macros. These conflict a lot. > > There's the low-level allocation issues. Right now we know what memory is > used by what because we have malloc enhanced to track this (oversimplifyi= ng > a lot I know). So we'd need some framework to make it easy to have 'custo= m > allocators' that could track it as well. At a bare minimum, we need the > runtime support for new and delete... > > > This is not technically required, but it is a good idea to think about > what the right strategy is. A C++ class can implement its own `operator > new` and `operator delete` wrapping `malloc(9)` and then subclasses will > allocate with that. Similarly, things like `std::unique_ptr` can take an > explicit deleter. > > This can be a bit clunky and it=E2=80=99s probably a good idea to have so= me > sensible defaults. > > Next, there's all the other run-time support that's provided by > compiler-rt. > > > Nothing in compiler-rt is needed for C++ except the unwinder if you want > exceptions (no one else except NT uses exceptions in a kernel). The one > bit of libcxxrt that you would probably want is the support for guard > variables, which would need modifying to use kernel locks. This is fairl= y > small, I wrote a custom one for CHERIoT RTOS which uses our futex APIs. > > Next, there's the issues of exceptions. They are quite useful for RAII > (since you know dtors will get run when an error happens), and there'd ne= ed > to be some sane plan for these (or we'd have to forego them). > > > Most kernels disable exceptions. You absolutely do not want Itanium-styl= e > exceptions in a kernel because they need to allocate to throw exceptions > and so you would only be able to throw from places where allocation is > safe. Given that the most common place you=E2=80=99d want to throw an ex= ception > (if you had them) is if `malloc` with `M_NOWAIT` failed, this could be a > problem. > > NT uses SEH exceptions, which allocate all of the state on the stack and > then run funclets for cleanup. It would be possible to support this in t= he > kernel (the relevant patents expired over ten years ago), but a non-trivi= al > amount of work. If someone wanted to do the work, it would be great: SEH > is one of the very few things I really liked about the NT kernel. > > Finally, there's getting the subset of the standard library that's useful > into the kernel. There's a lot of templates for facilitating RAII that ar= e > needed, for example, and some subset of STL, etc. > > > You don=E2=80=99t need templates for RAII, RAII just depends on destructo= rs. > Templates are useful, but largely orthogonal. I=E2=80=99d personally rec= ommend > against using much of the standard library in the kernel because it does > not have good ways of handling allocation failure without exceptions. Th= e > C++ standard defines a Freestanding profile (similar to C) that includes > things like the type traits that are useful for compile-time > metaprogramming. There are a few bits you might want to pull in but a lo= t > more that you=E2=80=99d want to avoid (I actually have iostream working w= ith the > kernel=E2=80=99s printf family, but it was a terrible idea and no one sho= uld ever > use that code). > > For example, `std::shared_ptr` is probably not a good idea (it allocates = a > separate control block to hold the ref count), but something that wraps > things that are intrusively reference counted with `refcount(9)` in smart > pointers would be valuable. Using member pointers, it=E2=80=99s easy to = build a > smart-pointer template that takes a C type that contains a refcount and a > pointer to the field and automatically manipulates the reference count wh= en > you copy the pointer. > > Once you have those 'table stakes' issues out of the way, you'll need to > see how it performs, and work out a few dozen logistical issues surroundi= ng > what compiler flags to use, what language features to enable/disable, how > to optimize and what set of warnings are sensible. > > > -fno-exceptions and -fno-rtti is what most peopls use for kernel > programming (there are a few dozen kernels written in C++, it=E2=80=99s n= ot like > we=E2=80=99d be the first to try). > > You could start using C++ with just the second of these items. > > > You can use it within a single kernel module now, as long as you resolve > COMDATs prior to linking and #undef a bunch of things. I was doing so fi= ve > years ago. The build system actually supports it already, though possibl= y > not deliberately. > I did C++ in the kernel in the 4.x->7-current time frame. I stopped because g++ was still evolving a lot in that time period and things kept breaking... and our use of C++ wasn't so big that rewriting in C was hard when one of the compiler updates in base broke something. A lot has changed since then and I'm just extrapolating from that... your experience is much more recent. Warner David > > --000000000000578a3f06219eff80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 8, 2024, 9:05=E2=80=AFAM David Chisnall &l= t;theraven@freebsd.org> wrot= e:
On 8 Sep 2024, at 14:50, Warner Losh <imp@bsdimp.com> wro= te:

So there's four big issues with C++ i= n the kernel, all surmountable if we wanted.

There are two missing from your list, which I enc= ountered when I wrote a kernel module for FreeBSD in C++ a few years ago:

C++ relies on COMDATs quite a lot.=C2=A0 Each inlin= e function and each function that=E2=80=99s instantiated as a template is a= separate section with some flags indicating that the linker / loader shoul= d keep one and discard the rest. If you have a single C++ module, this is f= ine, but for two it=E2=80=99s harder.=C2=A0 I did a small =E2=80=98libkxx= =E2=80=99 module that provided a subset of libc++ for use by different modu= les, but the kernel loader code didn=E2=80=99t have enough comments for me = to understand how to fix it. I would be tempted to approach this with a use= rspace tool that runs over a set of kernel modules and pulls out duplicated= COMDATs into separate modules that other things can depend on.=C2=A0 Alter= natively, the kernel loader could be modified to load only referenced COMDA= Ts, reference count them, and not load unused things from each kernel modul= e.=C2=A0 The latter is a cleaner approach but is more work.

<= /div>
Second, between 11 and 12, someone decided to replaces a load of = static inline functions in kernel headers with macros.=C2=A0 These conflict= a lot.
=

There's the low-leve= l allocation issues. Right now we know what memory is used by what because = we have malloc enhanced to track this (oversimplifying a lot I know). So we= 'd need some framework to make it easy to have 'custom allocators&#= 39; that could track it as well. At a bare minimum, we need the runtime sup= port for new and delete...

This is not technically required, but it is a good idea to think ab= out what the right strategy is.=C2=A0 A C++ class can implement its own `op= erator new` and `operator delete` wrapping `malloc(9)` and then subclasses = will allocate with that.=C2=A0 Similarly, things like `std::unique_ptr` can= take an explicit deleter.

This can be a bit clunk= y and it=E2=80=99s probably a good idea to have some sensible defaults.

Next, there's all the other run= -time support that's provided by compiler-rt.

Nothing in compiler-rt is needed for C++ exc= ept the unwinder if you want exceptions (no one else except NT uses excepti= ons in a kernel).=C2=A0 The one bit of libcxxrt that you would probably wan= t is the support for guard variables, which would need modifying to use ker= nel locks.=C2=A0 This is fairly small, I wrote a custom one for CHERIoT RTO= S which uses our futex APIs.

Nex= t, there's the issues of exceptions. They are quite useful for RAII (si= nce you know dtors will get run when an error happens), and there'd nee= d to be some sane plan for these (or we'd have to forego them).

Most kernels disable excep= tions.=C2=A0 You absolutely do not want Itanium-style exceptions in a kerne= l because they need to allocate to throw exceptions and so you would only b= e able to throw from places where allocation is safe.=C2=A0 Given that the = most common place you=E2=80=99d want to throw an exception (if you had them= ) is if `malloc` with `M_NOWAIT` failed, this could be a problem.

NT uses SEH exceptions, which allocate all of the state on = the stack and then run funclets for cleanup.=C2=A0 It would be possible to = support this in the kernel (the relevant patents expired over ten years ago= ), but a non-trivial amount of work.=C2=A0 If someone wanted to do the work= , it would be great: SEH is one of the very few things I really liked about= the NT kernel.

Finally, there&#= 39;s getting the subset of the standard library that's useful into the = kernel. There's a lot of templates for facilitating RAII that are neede= d, for example, and some subset of STL, etc.

You don=E2=80=99t need templates for RAII, RAII j= ust depends on destructors.=C2=A0 Templates are useful, but largely orthogo= nal.=C2=A0 I=E2=80=99d personally recommend against using much of the stand= ard library in the kernel because it does not have good ways of handling al= location failure without exceptions.=C2=A0 The C++ standard defines a Frees= tanding profile (similar to C) that includes things like the type traits th= at are useful for compile-time metaprogramming.=C2=A0 There are a few bits = you might want to pull in but a lot more that you=E2=80=99d want to avoid (= I actually have iostream working with the kernel=E2=80=99s printf family, b= ut it was a terrible idea and no one should ever use that code).
=
For example, `std::shared_ptr` is probably not a good idea (= it allocates a separate control block to hold the ref count), but something= that wraps things that are intrusively reference counted with `refcount(9)= ` in smart pointers would be valuable.=C2=A0 Using member pointers, it=E2= =80=99s easy to build a smart-pointer template that takes a C type that con= tains a refcount and a pointer to the field and automatically manipulates t= he reference count when you copy the pointer.

Once you have those 'table stakes' issues out of the = way, you'll need to see how it performs, and work out a few dozen logis= tical issues surrounding what compiler flags to use, what language features= to enable/disable, how to optimize and what set of warnings are sensible.<= /div>

-fno-exceptions and= -fno-rtti is what most peopls use for kernel programming (there are a few = dozen kernels written in C++, it=E2=80=99s not like we=E2=80=99d be the fir= st to try).

You could start using C++= with just the second of these items.
<= div>
You can use it within a single kernel module now, as lon= g as you resolve COMDATs prior to linking and #undef a bunch of things.=C2= =A0 I was doing so five years ago.=C2=A0 The build system actually supports= it already, though possibly not deliberately.

I did C++ in th= e kernel in the 4.x->7-current time frame. I stopped because g++ was sti= ll evolving a lot in that time period and things kept breaking... and our u= se of C++ wasn't so big that rewriting in C was hard when one of the co= mpiler updates in base broke something. A lot has changed since then and I&= #39;m just extrapolating from that... your experience is much more recent.<= /div>

Warner

David

=
--000000000000578a3f06219eff80-- From nobody Sun Sep 8 21:11:29 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 4X22hQ0Z9sz5W7ll for ; Sun, 08 Sep 2024 21:11:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X22hP1VpJz4TTJ; Sun, 8 Sep 2024 21:11:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id BA3768928E; Sun, 08 Sep 2024 21:11:30 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 488LBTtI074660; Sun, 8 Sep 2024 21:11:29 GMT (envelope-from phk) Message-Id: <202409082111.488LBTtI074660@critter.freebsd.dk> To: Warner Losh cc: David Chisnall , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> <0BC57127-5CF9-45C5-9BE6-7E21D2313291@FreeBSD.org> 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: text/plain; charset="us-ascii" Content-ID: <74658.1725829889.1@critter.freebsd.dk> Date: Sun, 08 Sep 2024 21:11:29 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X22hP1VpJz4TTJ Warner Losh writes: > I did C++ in the kernel in the 4.x->7-current time frame. The logical progression of C++ adoption would start with using a C++ compiler as a better C compiler. Even if we never allow a single thing from C++ to be used, that is still an improvement in terms of warnings and errors. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Sun Sep 8 21:50:25 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 4X23YH4bWLz5WF59 for ; Sun, 08 Sep 2024 21:50:27 +0000 (UTC) (envelope-from leres@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 4X23YH41T7z4YlW; Sun, 8 Sep 2024 21:50:27 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725832227; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9iXgpmIVqLpaNlYNK9qFIdBEcf8T4exwO/XACB9x3RU=; b=jA6XWIF31Y9w1SQDvltBgNq9mxH2xONJi3rhtY1l6Df6itOzYcS/waxriOjQIw64Y9n8Ex N60I4P61KxCeEldfkgRzFya/EM9y51sJ9WFSufwtmmP8XGhkVjRgTJ3+em4/MbxQWfL8U9 UHHqYtXHgEtGaOBkbDmuIJYg+eykzb2CDkuQZ1VHngZD1j1S4u9cvj0SYBfMqQA+SYr22N 3YZYszNYNYR1jX0EYNVh2v0DfMaCtVKzultxxvGhofq6GtmaoYIEOwZ4wg9PEuMZl9ZuX4 ERvK3pScHTvd4ieqymBn1pz5T6wjQmBFCqYwJ5bFBUcJ5Y2JVC3BCAWYJvLBtw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725832227; a=rsa-sha256; cv=none; b=nsmrCBf1lBc5mH9s+uh6XMuSCn3ATx8f3MwLTdxTZAFglkt6tsSGE2UZzqE7dem+ldUpKG nBoqyPT0/S1f1rtoKNdvxEfV5buT7dORDyW6rwcB+hXTobb3Q5eV7dvrSLv3K8+kMTblQw v/0LyFhKxG/Vmnr3hvT/5kWmcdt+a+ffou9mjR+WL7wbIQ5ppA5gC+swgyL7SQlcET4FM4 BMYhyzr9SKiDykNXAJN69ATbx8wipruIKnB0cuLQivd0sGq/rPcxtufEVH1RHn1YeQAWhw a/idqR8SedKOy+CFZ9ieqFu22Ikjry/NM98p4HwJryLZ+3WXX1UhRrsndkzSFQ== 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=1725832227; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9iXgpmIVqLpaNlYNK9qFIdBEcf8T4exwO/XACB9x3RU=; b=DZSfcVIhmmhgIG/ExUUXuiGRDn+e/lveRMrUK0GzN6JK+m+f+2Q3zqm/SWQ0qC5bemjeG4 JyBJ8nreHvTjtNxuGT5CHhicUojCYI8xeRG+ef6pAEsUB/4txA5/vfOwnzFQ9wghtIZt6x BhxZqVSAvJlp0vjHRY68OsuOF8QZqxaJ07EFgBw4Yi+Mf+MFutHZv/igZnc6baMHJ1Orr/ IYeVpi34gbaffofJ4FGE4FTJDegl1qi1G3c2+Q89QPRyfU9OX3no2wkPxOJf8Rhu43BRIZ fvSzM0dcKyzMIifb9EW8m+yiWKlzzMZkyQRZctuavLLWp0W3wEIFmkHGYeK7MA== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X23YH0jjmzb1v; Sun, 8 Sep 2024 21:50:26 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: Date: Sun, 8 Sep 2024 14:50:25 -0700 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? To: David Chisnall , Mark Delany , Dimitry Andric Cc: freebsd-hackers@freebsd.org References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> From: Craig Leres Content-Language: en-US In-Reply-To: <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/8/24 04:48, David Chisnall wrote: > If I mount the same share, I can reproduce this: > > $ mkdir tmp > $ touch tmp/foo > $ mv tmp fmp > mv: rename tmp to fmp: Operation not supported > > So it appears that something in the FreeBSD port of Samba has broken the > ability to rename directories. Nice catch. I installed 4.16 on a spare system and setup a test share. I'm able to reproduce your "Operation not supported" test. But I also see that (from the mac) I get the same error if I try to remove tmp/foo! I'll add some info to your PR. On 9/7/24 02:51, Mark Delany wrote: > I'm going to ask a silly question here. But why are people running samba instead of > netatalk if they are only using the timemachine backup capability? In my case when I upgraded to big sur (2021) it looked like netatalk3 no longer worked; my local osx expert thought that apple had phased out afp support so I switched to samba413. It wasn't until much later that I figured out when you make changes you pretty much need to nuke your old backup and start over. And also delete and recreate the share config on the mac. So maybe if I had just done those things when I upgraded to big sur I would have continued to use netatalk3. But last year I got a brother multi-function printer and it was pretty easy to create a samba share that the printer can store scans to. That's been pretty handy so I'm likely to keep samba. On 9/8/24 05:29, Dimitry Andric wrote: > I have never needed to explicitly set fruit:posix_rename, my Time > Machine backups work completely fine without it (maybe it defaults to on > now?). I have been using Samba 4.19 since the port came out too. Right, fruit:posix_rename defaults to "yes" (see man vfs_fruit). Craig From nobody Sun Sep 8 22:30:17 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 4X24T95Wgtz5WL3f for ; Sun, 08 Sep 2024 22:31:57 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4X24T91MfKz4fy0 for ; Sun, 8 Sep 2024 22:31:57 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=snzlgRp2; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="R anzcY2"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.148 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 1999213801D6 for ; Sun, 8 Sep 2024 18:31:56 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-05.internal (MEProxy); Sun, 08 Sep 2024 18:31:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1725834716; x=1725921116; bh=uD/+TXSeRIn8dnlSY0573cxeMbCXJD7A0/YwcCYL8wo=; b= snzlgRp2TttnFmZuTqVtC66o9TEMZYRKNg146/vMHUQ/xCIDWd4QOCxBDnxOo+4l Jxw0GsSYlPMkgU+B5pelXhCWaiUopWGo5QZhQR8jSDIS4FMgP8GxMeu07yLDT91T sHj+CMHJJO9/jw5fKYjWO3WZxT+hzlH33djVlCK6r/JP1RAN/49Nb2QQNCOsQN0x PWvvuGGgdTu2e8vlvwrugUo+8xnT0PDqawMChfEUYvZ8em6nmecan5jifcsXLAlX mlkbjQ/FHWmrTEKYn+iXXp2x2XTJNqtseGUuvaxML7kT0yEDFoFL3mrK4X+SrxsP gYM2UmTEOayQvvqbSnTYKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1725834716; x= 1725921116; bh=uD/+TXSeRIn8dnlSY0573cxeMbCXJD7A0/YwcCYL8wo=; b=R anzcY2OurlIjGSBC3HtB6h9rA1VZdD4ud+VDtBM0vSx0/Oi8oHSBTcijex2nPhFM oBRO4IdvpYOxajix9ouhBBC0SmJUyYwgmG+yH4pabkI/YhptKBczs1nmWJEu7pdl XTPgJOGQr322sn70GCOcQpYIKFRt75F73iGPtPdsqVui1Wfr+ON4Y+UkrYCqRtiZ fwGeh3kTjKUmYI3yR8w9QLVrBrbhz1UQ9WdglgyrwUYpxG3U5h112tVIG9VIf3VR DjuVT1VlBBf6e9iAUQjzf4+ywN1vXUSjsa+uD/lQh3CFogaHGS+EoAdX2B6QNhk3 7GeFuxegTuumeFNFhVsOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiiedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdq mhdrfhhmqeenucggtffrrghtthgvrhhnpeeitdefieefteeiffeffefgjeeuveffledthe ffgedtfffhfeeugffguefhkefgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhs sehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D914A2E60075; Sun, 8 Sep 2024 18:31:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 Date: Sun, 08 Sep 2024 23:30:17 +0100 From: void To: freebsd-hackers@freebsd.org Message-Id: <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.148:from]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.148:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4X24T91MfKz4fy0 Hi, On Tue, 3 Sep 2024, at 16:32, Poul-Henning Kamp wrote: > A FreeBSD system with no installed ports is a rarity today. I have 3 such systems. There may be more people running plain systems than you think. There's no way to tell. Although i concede most systems will have ports installed. > But a FreeBSD system recompiling itself from source is even rarer. ? really? All my -stable and -current machines are recompiled from source. Is this really that rare? > We need to find a contemporary and useful answer to "What is FreeBSD?" I've always thought of it as "freebsd is an OS". [1] I couldn't care less if the compiler comes from somewhere else ultimately, as long as it works and has a BSD or similar permissive licence. Everything ultimately in some shape or another comes from somewhere. If it's in src/ then it's FreeBSD IMO. > The only answer I can think of > ------------------------------ > "FreeBSD is ports (some of those ports contain the kernel and userland)" Oh I hope not... ports can sometimes be a nightmare. The separation of OS and ports is a great thing to have and is a freebsd 'selling point' IMO. One can easily deinstall all ports and blat /usr/local/* then reinstall, in order to recover a damaged system, for example. > As part of the migration, we yank LLVM out of the src. > > 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. > And yes, we have ports written in Rust, why do you ask? I don't think the benefits of tight integration are microscopic, at least not to me. I'd rather have kernel modules in src than in ports, including the video and wifi stuff. ports get out of sync and breakage happens. This seems less of an issue for src. At present, we have to install pkg to even get a tool for downloading sources. FreeBSD as OS is in that sense incomplete (again IMO). Why isn't got or git@tiny in base. We used to have svnlite. [1] If freebsd goes entirely to pkgbase, would it then really be an OS or just a distro? (eg 'linux is a kernel') --