From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: plum.tunbury.org; dkim=pass (1024-bit key; unprotected) header.d=inria.fr header.i=@inria.fr header.a=rsa-sha256 header.s=dc header.b=riwy0gfi; dkim-atps=neutral Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.134.164.83; helo=mail2-relais-roc.national.inria.fr; envelope-from=caml-list-owner@inria.fr; receiver=tunbury.org Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by plum.tunbury.org (Postfix) with ESMTP id 1E0FA400D3 for ; Tue, 20 Oct 2026 15:38:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=mime-version:from:date:message-id:to:subject:reply-to: sender:list-id:list-help:list-subscribe:list-unsubscribe: list-post:list-owner:list-archive; bh=LfNlZoNyRtffvStasqZF4g2aHAjx0Kj5FgD4ZzWaxgI=; b=riwy0gfih33xL8woMgldejtXcQQvwwvYQW8GO85LNcd6c1g/1RNg49ri c4TUZ882yyfpcCBrzRir27NImOfJ82eq6uLYNs9pWb7ZzVFEYguWs+nlr qgSGU1kSNg5mTQH0P4bH2Hgi6LajU3jdyRzv+P0IDm5c128wroiLjJbOI w=; X-CSE-ConnectionGUID: TxUjJEfsStWkLGQL6XpHZw== X-CSE-MsgGUID: 7DAN+vsPRd2xNtpk0+9jCQ== Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=caml-list-owner@inria.fr; spf=None smtp.helo=postmaster@prod-sympa-app.inria.fr Received-SPF: SoftFail (mail2-relais-roc.national.inria.fr: domain of caml-list-owner@inria.fr is inclined to not designate 128.93.162.27 as permitted sender) identity=mailfrom; client-ip=128.93.162.27; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="caml-list-owner@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3 ip4:128.93.162.88 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@prod-sympa-app.inria.fr) identity=helo; client-ip=128.93.162.27; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="postmaster@prod-sympa-app.inria.fr"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.27,168,1787004000"; d="scan'208,217";a="301183140" Received: from prod-sympa-app.inria.fr ([128.93.162.27]) by mail2-relais-roc.national.inria.fr with ESMTP; 20 Oct 2026 17:38:47 +0200 Received: by prod-sympa-app.inria.fr (Postfix, from userid 990) id 1E8B780D2F; Tue, 20 Oct 2026 17:38:47 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by prod-sympa-app.inria.fr (Postfix) with ESMTP id 26501804D1 for ; Tue, 20 Oct 2026 17:38:40 +0200 (CEST) X-CSE-ConnectionGUID: 0h6ZuQbXQaKD/3BOR0h8kg== X-CSE-MsgGUID: sR0zXdXwS7qceLajYcsdkQ== IronPort-SDR: 6ad78afe_9J7UK5glO5DUXoZ79v+YhKAinIWka+zYQ9GemkWnT2tDw2P fklv5GbjCZq8n5Tk10OoR7nfSRF7ZeEj63ba2gw== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A0GYJAD4iddqfLOAVdFSCIJZAoI/gQtgGhoEC0lkg3SBI?= =?us-ascii?q?0CBbIwDgiGBFiGQFo12AxgWBSICDwEDAQ00HQQBAQECAQOCC4E8gTeOGAIeB?= =?us-ascii?q?wEEMwYOAQIEAwIDAQEBAQEBAQEBAQELAQEBBAEBAQIBAQIEAwEBAQECEAEBI?= =?us-ascii?q?hkHDhIphk8NSQGJSAGCBzRLCB5gAQIBAwEDAgcBAQEBAQEBAQEBAQEBASIBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCCAUCHWAEG?= =?us-ascii?q?wEIBBkBGxIDAwYDAREDDSYCBQEJAiMBEQEFASIbDAeCZwGCIgEGEAEDECcDE?= =?us-ascii?q?QaZeI0KgyKKJhs3en8WBQIWgQGCDQaBCj4FDQMPL9hQChkoDXIDgQxcAgcWg?= =?us-ascii?q?TeEeSpPDgGCPwMcAXRsAQIOhEyDGYEfJw+BVUSBFTWBdEqCRgF5FwEBAQEYg?= =?us-ascii?q?R8PKRwhCwcCgnmCagSCInoSgXgFWwUIAoYojHYmCAcXAwcHCQUEHAYFBQI/C?= =?us-ascii?q?QUBDxIDBAMEBAECCwkKCQMDAg4CCAMCCAYZAT8SBBMKDQsHBR8KAgwWCigiE?= =?us-ascii?q?isKAQIBVTABCAYCAgQEAgQMAgMGAgIFBwIRAwQBAQgCAi0DAQMZCAkIAgsFE?= =?us-ascii?q?RgMCwcxAxAJAx8XFggRNAgGFgEaBgUGCzcVBQwRAQIbAh8EHREIAwEUBAIBC?= =?us-ascii?q?QMEFgQCFAohBwIOCAMDAwQCAwMDAwECAwEDAwQHAgEDBwICAwMDCwECAwMFA?= =?us-ascii?q?wMFBQICBQUDBQICCgIDAwMCAQMCDAgDBgMSARADAwYDBwMHAgQDCQIIAwMIC?= =?us-ascii?q?AMXAwMFAQICBAMDCAgEAwMEAgIDCwUDAgMDBQMDBwIEAgQDAwEFAQIHAgMHA?= =?us-ascii?q?gEYAwIECAcHBQILBAIIBA0JBAIEAgIPBAYDAwcBAQIBBwUGAwICEAEICgUGA?= =?us-ascii?q?gICHAMeAw0BCQUCAQUOBwUCAhgDBgIDBgUBAwEJCwEBAgMKAQIEAgUDAwEDA?= =?us-ascii?q?gMCBgMDAgUFBQMJBwUVAQMDBgUCAgMCAwECCAQGBQMCAgMFAQMEAwoDAggDA?= =?us-ascii?q?wgDDAIaAgUDAwMGCQMHBwIDBwMCBQIHBQMDBQMGAQMCAQMDCAsSHwMDAQUDA?= =?us-ascii?q?wIBAwIFAwMYAgIEBQMDAwMDCAQCAgEHBgQCAgIBBQUFBAUGAgQDCAEBBQMDC?= =?us-ascii?q?g0BAgcMAwwGAwcDAwQEAwIFCgIEAQcNBwkHAwIDBwEBCwQBAwMKAwMFAgEBB?= =?us-ascii?q?wUDBgMHAgMDAwUEBQMCCwMHAgIDAwMCJwEBAQMDAwMDBAMBAwEDAwcDBQMCE?= =?us-ascii?q?AcBAQoDAgYDBwYDBQMDAgECAwMFEQMGBAUGFwIGETIBCAIDAwEUBAQFAgUVA?= =?us-ascii?q?ggBAwUDAwMDAgUDAQUBAQMDBQMDAwMDAwQBAwQCAwcGCAEBAQIIAwMCBQMDA?= =?us-ascii?q?wQDAwIBCwQCBQMGAgIEAgQBBwMBAgIDAwMDAQIEBAIHBAUCCwMEAgMDBQIDA?= =?us-ascii?q?gMLBgILBAIDAwMDAw0BAgsGAxQFCQQIBQMPBQEFBwcJAQMIBQMGAwsDFAMDB?= =?us-ascii?q?gMDAwoEAgUBBg4MDQQBCQMCBAIOFQQEAwcCCgsBAQQMAgMEAQQBAgIGFQIIC?= =?us-ascii?q?QYHAQgCAgUCAgIDAwMCBQgCBQIGAQQCAgcCBAkDAgMCAgIIAQMCBAEHAgIDA?= =?us-ascii?q?hkBBAwJCBM9AQsHMgQ2ARUUBSkhX5E6GYJCPAYCDR80Ew4CCgEKGQYBASAuB?= =?us-ascii?q?gkXHQoQCREVBCUBGwkECwgJAhwCDwOEYIgthUoQFAEuAgOPWKIPbTQHhCGBY?= =?us-ascii?q?AaKPI40hyAzhASBV6UUiASOIYJjglmGKIEAgSYJgW9rhSWDVYcbhQ8QKQMvB?= =?us-ascii?q?IUVESQSgRwsJDyBIHBQMYI2CUcDGQ+OACsDBRGDYBCCVAOBOFAkPB6BF8V2R?= =?us-ascii?q?zICAQEHNAcCBw8ChjQigkmIVjJrBF0BAQ?= IronPort-PHdr: A9a23:HI82fRZ+BKwSpCmWfa8rNef/LTGX34qcDmcuAnoPtbtCf+yZ8oj4O wSHvLMx1wGPBd+Qsqkb17CempujcFJDyK7JiGoFfp1IWk1NouQttCtkLei7TGbWF7rUVRE8B 9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9I Ri4rAjdrNUajZVtJqosxBbEoHRFd/pLzm50OFyfmArx6ci38JN/6Spbpugv99RHUaX0fqQ4S aJXATE7OG0r58PlqAfOQxKX6nUTSmsZnQNEDhbK4h/nRpv+vTf0ueR72CmBIM35Vqs0Vii47 6dqUxDnliEKPCMk/W7Ni8xwiKVboA+9pxF63oXZbp2ZOOZ4c6jAZt4RW3ZPUdhNWCxAGoO8b pUAD+wdPeZDsoLxo0ICoQaiCQWwAe/izDhHiGLr3a0hy+QuDx3J3BAuEdIJtXTbttT1NKEPW uyxw6TFyTDPYvVL0jn/9YfIaAgsrv6MU7x+csTf1FchGB/eg1qKtYDoJSmY2vgRv2WZ6edrS OKhi3QgqwF0ujWh2sAsiozTiYIUzFDP6Dt0z5wxJdKiU050fd+kH4BOuCGGK4t5WN4pTmZyu CY9z70Jo5+7fC4QxJs73RHfb+aIc5OU7RLiT+mePyt4hG5/d7+kiBay9FKvyuz4VsWuzFlKq S9Fn8DKu3sQ2BPd9tKJReFh/ke9xzmPzQbT5/lALE00iKbWNZ4vz78/m5cPvkrOETP7lUTrg KOLdkgo5+ul5uvnb7vmuJKQKZJ5hx3iP6kqhsGyAuA1PxUOUWSH/+m3ybPt/Ur8QLpQj/02l LHUsJfGKssBo665BxVZ0oE56xawFzumzdIYnXgELF1bYhKLlY7pO1XWLPD9F/i/glKsnC1ux /DCJrHhGJLNIWPekLf7Z7py90lcyA0rzdxH/ZJbFLEAIPTpVk/wrtzUFhg5MxeuzOb6Etl9z J0RVXqKAqCDMaPStV6I5uQgI+mIfoMVoyr9J+A+5/7uk3A5g1sdfa610psQdX+3AO5qLFmeY XrpmtsBHmYKvhY+TOz3k1KOSyRfaGq1X6I5/j07B4OmDZvDRoCwm7ONxju0HppTZmxeBVCMF 2roe5+DW/cWZyKeOtNhnSYeVbigVoAuywquuBXmxLpgK+rY4jcXtZL51Ndr6e3Tjgs++iBzD 8SYy22NQGZ0nmQHRz8ywq9zu1ByylCG0aRgjPxYFMBT5/NUUgghL5Lczut6B8j9WgLbZNiJR kypQtO8Dj0rUt0xxNoOb158G9WkgBDD2zeqArAImLORGJw76LjQ0GT2J8Z403rG07UugEMjQ stLLW2mnKl/+xLPCI7OlkWVj6GqergG0y7I8GeP1HGOvE9CXA53S6XFUmgTZlbQrdT45UPNU aWuCbI5PQtF08KCL69KZsXzjVVBX/jjJc7eb3itlGe3AhaI3qmAbIvse2gbwS7TC1AEnhgN8 XqaMQUyHCSsrmLEADBzC17iYFng/fR8pX6/SEI/0huEYFd717Wv/x4YnfycRO0X3rIDoCohr i97HFe5397PC9uBqRdtcLxSYd8g4lpK0XjVtwN6PpynIKBigkARfx5rsEPp0hV7EoRAkc40o 3M21Ad+N76U3Vdbez6b3Z38IKDbJnfx8Ry1dqLb2FXT3M6T+qgV6fQ4r1vjvBuuFkon63hny d5V036G6ZXLCgoeS47+XVwz9xdgvLHVfig96JjK2n1wLam7qCTP290sBOQ/yxage81TP7+DF A/3C8EaHdShKPQ2m1i1aRIJJPxd+7QxP8OibveG3K+rPP18nD+9lmRG4IV90lqW+CZmS+7I2 YwFw/CC0QedWTf8lk+tssbslo9cfzEdAnK/yTT4BI5WfqB+YJ4HCWiwLM2wxdtwnYbgVHBF+ lK7HVMJxtGpdxmIYVHl2A1fz0UXoXi+lSq4wT14jiglrqSC0CHMx+nubhUHOmlMRGltiVfjP 5K4gMwdXEitdwQmiRil5Uf/x6VDvKpxIGfcT1lUcSXqKW9uSra/tr+YbM5V9JwlqT1ZXv2kb 16VUrL9uAMa0y37EmVE2D01aiykto3inxxihmKSNHZzo2TdecF33RrR/MXSS+Ze0GlOeC4tr hLeA1z0GtCo+dSSmN/ns/uiHzaqX5hXNC3q1p+otS2h5GQsDwfpzN6pndiyKw8/2C79n/JjU SzTpxf2b5X33uzuK+Vid0huQlT178NhEYB0n5csjbkf3HEbgtOe+n9RwjS7CslSxa+rNClFf jUM2dOApVW8sKUCBneAxoaiE26Y3tMkfN6iJGUfxiM66clOTqaS9r1N2yVv8RKjtQyER/97k 38GzOc2rmYAirQTvw8kzyPbCbkWFFJTPCbhiwiBx9+7paRTIm2odOv4z1JwyOioF6rKuQRAQ DD8c5YmEzV365BlN1fF0Xu14YjgccLbbNgeqgGduxjFhulRbpk2k6lCnjJpbET6u3Bt0Osnl Vpu0JW96ZCAMHlo9bmlDwRwMzT0Y4YC5Wiog/8Bz4CZ2IegGpgnETIONHfxZdSvFj9a9fHuN gLVVSY5tm/eAr3HWwmW9EZhqXvLVZGtLXCeYncDn51kQ1GGKUpTjRpxPn1yl4MlFg2s2M3qc VtorjEX6FnirxJQy+VufxDhW2bbrQ2sZ386Up+aZBZR6whD4Q/SP6n8pqppGCRR/5vnpwWJI 3eQZg5FEX0AckOBDlHneLKp4JiI8uSVAPa/M+qbea+H+ok8H7+DwZOi1Jcj/i7ZbJ3eeCk/S aRhigwaAiEqfqaR0y8CQCEWiS/XOsuSpRPnvzZystj66/PzHgTm+YqIDbJWd9Rp4RG/x6mZZ IvyzG50LyhV0pQUyDrG0r8aiRQIjCRndj/rGr0EvDXGTajdhrNeJxEeYiJ3csBP6uhvu2sFc d6ekd7z2rNi27QvDFJMVFqnkcitbNcBImuwKE/OLEmOPbWCYzbMxoukBMH0Aa0Vh+JSuRqqv D+dGEK2JTWPmQ7iUBW3OP1NhiWWVPBHkLm0aQ0lSW3qTda9Lwa+LMcyljouh7s9mnLNM2cYd zl6aUJE6LOKv2tUhfB2GmoJ6XQAT6HMgSGc5ujebJ0ftfJwCSV+mv5G6Vw1zrJU6GdPQ/k9l CbJr9Foqk2riaHVkmshAEcI82wbwtvU7A1rIsC7vtFYVGzB/Q4R4GnYEBkMq9Z/S5Xut61W1 tnThff2ITZG/cjT+Jh5ZYCcI8aGPXw9dBvxTWSMXU1VEHjybzGZ3hMMw5TwvjWPo5M3q4bhg s8LQ75fDxkuE+8CT19iBJoEKYt2WTUtlfiaitQJ7Dywtkq0Jo0Ss5bZW/aVGfiqJiyeiOwOf RwNyLL+a48aMoTg0E1oZ0VmlazFHkPRWZZGpSgrPWpW6A1dtWNzSGE+wRevcASo6X4VU/W9m hctgQp0bPgx/R/j5l42IhzBoy56wyxT0Z31xDuWdjD2NqK5W4pbXjH1u0YGOZT+Ww9pbAe2k B8sJHLeSrlWlbclaXFzhVqWp85UAfAFB/4hAldY1bSNav4vy1gZtii32RoN+77eEZU73AoyL czz8zQZgV8lNJhtYvWObKtRkgoK3vPI7nLuj7phhldZfhlokivaeTZW6hZQbuB0e3r2pr4wu VLeyWkEJTZEVuJ08Kg2rh9vZbTYl3C8g+AfeBL2arL6TevRunCex5TWGgxi2BMCzxsZreYqg 5VkLhTcVlhxnuHBT0xbbsSae10FMZYApj+OI0Ps+a3M2cwnZYzlTrKxEbLW5vpE3B72TkF0Q cwN9ppTRJL03hPWJ5q/fuJVl0l/tkO2eh2TBfBNMnpniR8hpMeyhN9y1IhZfXQGBHlldD6w/ vDRrxMrh/yKWJE3ZG0bV80KLCB+XsrygCNfs3laaVv/musE1AiP6SP9rSXMHXH9adRkfvKde RJrDpm/5zw+96G8jVOf/I/ZIin2MtFru9mH7u1/xd7PE/RPUbx0qFvRgaFdTn2uFn/QSJu7f sehLYYratPwBzCxVVn+wzM5QsHtPcq8e6iFhQa7IOQc+IKf3T0lKYq8DmREQ0Y297xFvfgsI 1RcMsleA1agrQk1Oq2hLR3N19yvRz3oMj5KV7xEyv38YbVLzi0qZ+v8yX06T5h8wfPklCxFD JwMkBzawu6uIodEVi2mUGZafgzOo2wynmxoLe0zyOoj3BrgvlwVMjTNf+tsIj8h3Zl0FRaJL HN6B3BtDUeblpbG6xWw0qo6+iJcm5NFzrQAviGh79nQZzWjXKHtopLQ+XlFD5Bus+h6NortJ dGDvZXVk2nETZXehQaCVTazC/tQntU4yMNwRfBJnSQ0JpVDt9MeuAw+UcAxI7EJA64p9OjCg d9MAisbzCtfXISFjmRqagiU1L7TlxPWe5MnYkVsjQ== IronPort-Data: A9a23:+IX/M62wdeiFkdSvIfbD5U91kn2cJEfYwER7XKvMYLTBsI5bp2YDz mIZCm2Ga6yDajf8et4lYYTg8kgHsZGAzodjHlBsqSg9HnlHgPSZOdnIdU2Y0wG6fpSSFho/h yk9QoCdd55sFie0SjOFaOWJQaxUjPnQLlbEILeafHg3GUk/EH1JZStLw4YRmpRvjcWyHzSDs Nbzp9y3EFK+0laYCEpNg064gE0p5quaVA8w5ARkO6kT5Q6GxxH5MbpGTU2PByugKmVrNrXiL wrz5OnR1n/U+R4rFuSknt7TGmUWQqTfNBS5kXFfXa6vmHBq/kTeBY5mXBa0QR4/ZwShx7id+ v0U3XCDYV5B0pn3pQgoe0Uw/xdWbfQXouefSZSImZf7I0XuKxMAyhj1Za08FdVwFu1fWAmi+ RGEQdykg9/qa++emdqGpudQassLdMm1Dp4msEFZxBL1Sq0MZqqbQ/XJ6ooNtNswrpgm8ff2Y sMYbX9+c02FbUQQaxEYD5UxmOrujX76G9FagAjN9Oxnvi6Kllw3iee8WDbWUoTiqcF9hEGdr 2PAuW/wBhgBP92VxCaZ+1qjg+bOmWXwX4d6+LiQr6Ay2wzPmTJKYPEQfUCB+euJhn6hYI1GI EEw8ygfprM+93X+G7ERWDXj/Sfc4U9CMzZKKMUx4QSJj67V+BqxHXkBVjcHado8tcZwSyZC6 7OSt9bgBDgqoaLMDHzEqebSojS1NiwYa2QFYEfoUDfp/fG7oN8BkyvFfu9qM4Ly1ffSI2nwk zOF+X1Wa6oosSId60msEbn6b9+Eo5HISksk+VySUDv6v0V2Y4mqY4Hu4l/ehRqhEGp7ZgDZ5 BDoeODHvIji6K1hcgTTGY3h+5n0t5643MX02wIHInXY323FF4SfkX9sDMFWfxowaplVJ1cFk WfcvgRe4JIbPX2hK8dKXm5FMOxzlfKIPY29CJj8N4MSCrAvLlPv1H81Pia4gTu9+HXAZIllZ f93h+72UC5CUcyKDVOeG48g7FPc7npvnDqKGsGik0nPPHj3TCf9dIrp+WCmNogRhJ5oai2Mm zqGH5LSm08NY/60eSTN748YIHYDKHVxV9i8qNVaeqTHakBqEX0oQa2Zi74wWZ1Xr4IMnMfx/ 1a5RhB5znj7jib5MgmkUC1oR47uepddlkgFGxIQE2ym4UV+Xrb33pwjL8M2WZIF6N1cyeVFS qhZWseYXdVKZDf12xUcSpjfvYY4LRSiul6TDnCLewkPWZxpeC7N9v/efjLA+DU/MS6skc4Yv beb9xj6RKAbTF9IF/fma/OIznKws0MCmel0YVD6H9lLdGjo86loMybUjMJrB+09cjL42Sq81 SuNJAUx/Nn2vI4+9efWiZC+r4uGF/V0GmxYFTL56YmaGDb7/G2x551pS8eNIC7gUV3r9JWYZ el6y+/2NNsFlg1ot6t+C7Na8rIs1eDwprN1zhVWI1uTVg6FUohfG3ih2dVDkoZvxbUD4Au/Z R+py+lgYL6MPJvoLU4VKA8bdd+87PAzmATJzPELMU7/tT5W/r2GbB1oBCOyqhdhdZl7DIB05 t0amp8yyxe+gR8UINq5nnhq12CTHEchDYQjlL8nWbHOtCR662tsQ5LmDg3O3KqucPRJa0kjH S+VjvHNhpNa3UvzTEAwHnnsg8tbp4oEhz5Sxl5fJWW2itrO3Nkv7RhvqTgYYC1nlExH2t1sJ 1kxZlFUJLqPzRhslsNsT2ChICAfJRm75EbO5UMDlUf1fna4VmeXCnUMPNjV8G808mxnYTlQ+ o+D+lvlSTrHeMLQ3DM4fExY99jPfIdWzRLTvsKKBOGXNsAKWiXkiaqQemY4kRvrLscvjknhp +Mx3uJPRYDkFCwXsYspIpK70OkOdRW6O2Bye/Ft06cXF2X6ejvp+zyvKVi0S/xdNc7x7k60J Mx/FP1hDy3k+n61kQkaIqoQL5tfvv0jvoMCc4y2A182ieKUqz4xva/A8iT7unQQfOxvtsQAM aLUSSOJFz2BpHlTmlKVlvJ+BEiDXYAmajH/jcePy8dYM7IYseppT1M+7avsgVWRLzlc3ky1u CHtWvbo6tJMmKVWopvUM6RcBg+LB8v5e8aW/SuS7dlfT9P9Hv3flgESq1PYERxcFuJMV8Zai YaPnYXQ5x7DtuxnVWr2poSwTfhVxMStXdh4NtD8A2lakBCjBu7twUon0EKpJaNZlOhy4pGce DK5T8+rZPgpW9t5719EWRh0ShoyJfz+Ufb9mHmbsf+JNCk47SXGC9GWrVnScmBRc34zCa3UU wPbla6n2YFFkd5qGhQBOvBBBq14Kn/FXY8NVYX4lRucP1mSrmKygJnQvjt+1miTEViBKtjw3 rzdTBundBiShrDB/OsEj6NM5C8oHFRPqshuWHkC+uxGqSGwV08HCuU/Da8oKL9plg7K6ZWpQ w2VMUUDD3zxUw0RJF+4qJ7mUxyED+MDBsbhK3Z7twmIYiOxH8WbDKEn6i5k5GxsdyD+yP28b +sT4WD0IgP716QBqTz/PRBnqbwPKjLmKnM0FYTVlsXzB1MPHuxP2iU+TUxCUivIF8yLn0LOT YTwqaaoX2njIXMd0+45E5KWJP3dlDzqxjQsKyyIxb4zfq2FmfZYxqSX1/7bi9U+gQdjGFLKb XzyTmqJpWuR3xT/fEfvV80B2cdJNB5AIiR2wGIPi+Hfc2FcJ1nL5/8/oBc= IronPort-HdrOrdr: A9a23:DKthRqr42y3LV3bvaNHYRUMaV5ryeYIsimQD101hICG9Lfb1qy n+ppkmPEHP4gr5OUtQ4uxoXZPufZqyz+8Q3WB8B8bGYOCEghrLEGgB1/qF/9SIIUSXndK1vp 0QCpSWZueAdWRSvILV5E2WH9483MKK6smT9IDj5kYoYwUvRa8I1WdE48Wgc3GehjMpOXPxLu v+2vZ6 X-Talos-CUID: 9a23:FVehPmOqN+o70O5DACk5xlMtEPAce17xiyz6BHXgCTZqR+jA X-Talos-MUID: =?us-ascii?q?9a23=3AuXB3WQ4hAkFYIyNYmTpuwsBuxoxz2fy8OEw9jq5?= =?us-ascii?q?ZosKJESVyCjyGgDeOF9o=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.27,168,1787004000"; d="scan'208,217";a="160394761" X-URL-ContentFilter: X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown X-MGA-submission: =?us-ascii?q?MDFJoA6ffFvgarRJRI0khpeqmns1OXHBlD7inp?= =?us-ascii?q?3Mzt/Pvcs+jhx+qTOULSZsSuezdcnErMtBY+tgRM6tOwK20jiak5RgmI?= =?us-ascii?q?z19Rwvp0Y4y2qR1ijeaMsvMnp9/SHJOI9S1Bg2ukLrV5KaoPEzy4c4WT?= =?us-ascii?q?xzZuV3G4qfgkACUf716jeJTg=3D=3D?= Received: from mail-yw1-f179.google.com ([209.85.128.179]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2026 17:38:38 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-8ab38a051aaso29040967b3.3 for ; Tue, 20 Oct 2026 08:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1792510716; cv=none; d=google.com; s=arc-20260327; b=jfLDGEUM+ciuVeDblHdzoKzNp/pr5zczbP+HOfvW37Rr+3avFWU8CaMXuPHLI8RMhZ 3gTbxjxtKOTm6bmhtoQI9p106imwCKp+UUNZJqxndm9kDyB4JdYfL/QZsvFMiDNU9d8v rAFm0kcC3bmw6Gf9Z7Mai4mqAsoDYThFyqlgjDDvzvGp956kfJWWiExAatSx+Osf0rJK O3taJ2WDU7JT28VhOA2EOrIqSnIWPJwEUt5nsRmyQkPnZMA4w9W3YYySPPO098VZTXcd Hb7SQWmy8ClL0VaCXOOJdW4OIRBju18Wlyt8VpC+rGhM31Uy+jLVuE6IalOjfUBNUBL6 LJdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=LfNlZoNyRtffvStasqZF4g2aHAjx0Kj5FgD4ZzWaxgI=; fh=7qFuN68gAcmLqj71H49obuXXH9B/qDYMiCQIe21hbbg=; b=NYQY5uD/02PQ6M+e4ww+YgFBfI8fN4inB8wd2urMCZLKkrSj8kFwOU7i7GE1qV7tNH FTAqwd4MJu4F8xb+/Tg5yO7BTGptEBdRQVG7pXtUGItu9Y8YeUCTUEmIFR2+PR6AWYbP 2Hpn/lxQYctk7JHl9h5cfC4Nuh7wWi98sRAUK1Upw3oTuFmz5zfZgNH8PODEh5XDI9XN qJJVUFP7MWOZ05qFlrI+003enQOA+hKGDAQ/+7ty8OuIqoKkwlxlOAmVBm3HFvp1oVd5 OGjtz0AT8ZaP1TvEm1bGBrFY6Gaq0j4T/4M1VW9ucGNdujWrXH1oQnLJoCc38wBrsZvq pMsQ==; darn=inria.fr ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792510716; x=1793115516; h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LfNlZoNyRtffvStasqZF4g2aHAjx0Kj5FgD4ZzWaxgI=; b=XggcGDbPCoXPPMIywLKQxbefbR0wiFpVY6JkrjCT7oGaIJkesvyOfasAc7JqnSOre3 BxlAPB84vkA/yKPAElAVjX4PK+QnEAAbLE4PDjKFjbc/4LMwGMiGbq8SkUkBZ+RElOKt 874e4E/2FiiOhTCy5R6frE4G7527WhZPRMj7bO2i3pyJSkX9cmADldEkl37xv1yWtp5h XQk4iwSCAHfbFiOu5WrJGpaVLFgVMtreVrtDZ730qBQZN+wJr2iQ46xdnoBL5S8snT1g beD7XaxWKaT/W+kAecMK3MbjQjQiKaGkzYrZ9R8X4HjcycLmu+H8fL655RZ8eaU5HVN4 MWxA== X-Gm-Message-State: AFq9FYII6G1ag2/fUO278vHkPmtz8SAl6gz8/RNpDjjn59OluP+bp2uL iu6Db2GYW48pnp7NZl8gC53B3FAYMaeypKMRRmIttmxd/uNGpxH6juPgb8UD2jSmvvWlM4dmZq3 aonZcxpVnaPoVAZK1DqoLpRMP0M02/6ytK++2rUe6Nikx X-Gm-Gg: AYBFou0vfAKdyb9PldrgvXcAd6+9o9Gqgp4ZUPCRkIx5cRGevTxAE6d8oYzMaV7EN6f 17dXQk4IEaBGP6P2FicokR7B8YHbaSl5clGx7WIJK/vGPN9MyfDqs0mLlR+dsoYH4H3deSZSG8k FkJ0rPjrV2DvBnqoOcJ2Nqyf6lMLHbz/3ui09Bhqpz9hZpsgjiVAMKyLTUAxEZs5HOuTRqZGcIj fJ5AA8Z8H6GiEk6TPuIh92oWl9VYcnwitceQ2eZvlAhqKjB6v5pFoxORKtfJy8h3s310+k4Jr5X hXdPt9EfURou5QTr7Z8n6bMyfBgg8EsT7I8x+OTuYF2t4tfmbCdOx4ujOmZDTIatO/xGO6/oW7k k+9VAeu0iUCTgUw8ga03ZYMGCq5IK13mXrJw/U8Np2C/fJC/nUOzdTI1R1JmaqxEuMqzBFdfB5s lBgAqsEz3RFviGxkrFVubG7e+e8BnPHxi26bm6pz7C86AnFWCtkylQlFeIja4ZAFw/ejKX X-Received: by 2002:a05:690c:f04:b0:8b0:89ea:6aca with SMTP id 00721157ae682-8b0f205b7c7mr41154047b3.6.1792510715727; Tue, 20 Oct 2026 08:38:35 -0700 (PDT) MIME-Version: 1.0 From: Romain Calascibetta Date: Tue, 20 Oct 2026 15:38:22 +0000 X-Gm-Features: AclHuK9LP7zLe8_ABFLk1kCyvaqVHWiyV2hjd1dYyIB9YZdjZ8F4w4HEgSQ7lGw Message-ID: To: OCaml Mailing List Content-Type: multipart/alternative; boundary="00000000000077953a065e476c62" Subject: [Caml-list] uniker.nl - a new way to develop and deploy unikernels in OCaml Reply-To: Romain Calascibetta X-Loop: caml-list@inria.fr X-Sequence: 19597 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Archived-At: --00000000000077953a065e476c62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a cross-post in Markdown format that you can find here: https://discuss.ocaml.org/t/ann-uniker-nl-unikernels-in-ocaml/18625 We are delighted to announce the launch of our new website: [uniker.nl][uniker.nl]. This website embodies our new approach to developin= g unikernels with OCaml 5. It offers a new way of developing unikernels and now places just as much emphasis on the deployment and use of unikernels. The website features a comprehensive [tutorial][uniker.nl-tutorial] and resources to help you get to grips with our new ecosystem, providing a _first entry point_ for anyone interested in unikernels in OCaml. The content of this site is available [here][uniker.nl-repo], is powered by the excellent [YOCaml][yocaml] project, and is deployed using our [immuable][immuable] unikernel. ## Our new ecosystem We were able to present our new workflow at the [OCaml Workshop 2026][workshop] ([slides][slides]) and our approach can be summarised in two main points: - the development of unikernels - the deployment of unikernels and their uses ### To develop unikernels Our co-operative has been developing unikernels for quite a few years now. [Our blog][blog-robur] showcases some of the ones we use for our infrastructure. Based on our experience, we are well aware of the constraints and limitations of what we can achieve when it comes to developing an application in the form of a unikernel. The best-known constraint we have accepted is not to requir= e the POSIX interface (nor to attempt to replicate it) in terms of protocols and formats. One of the rules still adhered to today is, amongst other things, [not to depend on I/O or a scheduler][sans-io][1][sans-io-2] when providing implementations. Building on this experience, we have been able to develop protocols and formats that are currently being used by others in contexts other than unikernels. However, we have also seen the limits of what we can achieve, particularly with what MirageOS currently offers. With this in mind, and upon further reflection on the constraints we face when developing unikernels (particularly regarding cross-compilation), we have decided to structure the development of unikernels using two tools: [`unic`][unic] and [`mfetch`][mfetch]. #### [`unic`][unic]: how to infer dependencies and _vendor_ them One constraint we face with unikernels is the need to recompile C files wit= h specific options so that they do not depend on what already exists on the host system. The approach taken by MirageOS 3 was to distribute the result of this specific compilation within libraries that contain C stubs (such as [`digestif`][digestif] or [`mirage-crypto`][mirage-crypto]). The problem is that we were forcing users of these libraries to install [`ocaml-solo5`][ocaml-solo5] in order to obtain a compilation environment for C files specific to [Solo5][solo5], our core component for producing unikernels. MirageOS 4 then arrived with `dune` and its contexts, allowing us to achieve a consistent compilation environment for C files. However, this approach introduced new a constraint: all dependencies of our unikernels had to use `dune`, which is **legitimately** not the case in the OCaml ecosystem. It is for this reason that we decided to refine the need to recompile some of our libraries a little further and, finally, to be able to capitalise on a key advantage of [`ocaml-solo5`][ocaml-solo5], namely that compiling OCaml file= s with this compiler produces exactly the same result as if you were using your host OCaml compiler: in other words, and as has been the case from the beginning, we strictly only need to cross-compile the C files. It is therefore at the intersection of these two features (only needing to cross-compile the C files and being able to reuse libraries written in pure OCaml and compiled with the host compiler) that we can offer users the ability to write this sort of code without involving any maintenance work on libraries that do not use `dune` and without necessarily having to recompile everything: ```shell $ opam install unic $ cat >main.ml< open Digestif > let () =3D Mkernel.run [] @@ fun () -> > Fmt.pr "%a\n%!" SHA1.pp (SHA1.digest_string "Hello World!") > EOF $ unic infer -r . Module Digestif is provided by several ocamlfind packages: [0] digestif.c [1] digestif.ocaml Pick one [0-1]: 0 digestif mkernel $ opam source digestif $ opam source mkernel $ dune build $ solo5-hvt -- _build/solo5/main.exe --solo5:quiet 2ef7bde608ce5404e97d5f042f95f89f1c232871Solo5 ``` `unic` is therefore a tool capable of inferring the dependencies of an OCam= l project without using a specific build system, and of calculating what needs to be cross-compiled (in this case `digestif` and `mkernel` but not `fmt`) to produce a unikernel. The project serves our purpose first and foremost, but it is worth noting that it can also be useful when compiling statically linked executables. This tool offers a whole range of sub-tools for analysing META files, viewing an artefact from different perspectives (its module name, its `ocamlfind` package name and its OPAM package name) or analysing OCaml artefacts (such as `*.cmxa` files). We would particularly like to thank @Octachron for his [`codept`][codept] project (on which `unic` is based) and for working with us to improve it. ### [`mfetch`][mfetch]: how to vendor dependencies Having identified more precisely which dependencies need to be cross-compiled, we now need to download these dependencies. Although `opam source` does the job very well, we wanted a tool that could download the source code from variou= s types of source, such as: - from a _tarball_, as is usually the case - but also from a Git repository - or even from a specific location on your file system That is why we developed `mfetch`, which allows you to download software sources based on information provided by OPAM or the user, and to create a `vendors` folder containing all these sources. ```shell $ unic infer -r . -o _mfetch $ mfetch --with-dune-file digestif =E2=94=82=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2= =96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96= =88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=94=82 3.1 MiB / 3= .1 MiB 5.9 MiB/s mkernel =E2=94=82=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2= =96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96= =88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=94=82 37.3 KiB / 37= .3 KiB 3.4 MiB/s digestif ok mkernel ok $ dune build ``` `mfetch` also allows you to check whether you have modified any of the source files (for a bug fix) or to generate a `*.locked` file so that you can then verify the reproducibility of your unikernel using our other tool [`orb`][orb]. The tool itself is not revolutionary, but it helps to streamline the workflow. ```shell $ mfetch status digestif ok mkernel ok $ mfetch lock 2 sources locked into _mfetch.locked ``` #### Libraries for OCaml 5 Our new workflow now uses OCaml 5. As well as updating the basic building blocks required to produce unikernels with OCaml 5, we have also developed = a series of libraries that primarily enable us to take advantage of effects. Furthermore, over the past several years we have developed: - [Miou][miou-announce], our scheduler for OCaml 5 - [`mkernel`][mkernel], a derivative of our Miou scheduler designed to handle the I/O provided by Solo5 - [`mnet`][mnet-announce], a reimplementation of the TCP/IP stack (using [`utcp`][utcp]) in OCaml with effects - and plenty of other libraries such as [`mhttp`][mhttp], [`msendmail`][msendmail], [`mfat`][mfat], [`vifu`][vifu], etc. These libraries, currently used by some of our deployed unikernels, allow us to offer developers a _direct-style_ approach to implementing their unikernels= . But what is key to take away from this emerging ecosystem is the retrospective analysis of past projects to ensure we do not repeat the same mistakes. We very quickly realised that it could be very difficult to migrate existing libraries using [`lwt`][lwt] (the MirageOS scheduler) to Miou (or any other scheduler using effects). We therefore took the opportunity not only to propose a _direct-style_ approach using Miou, but also to rethink the implementation of our libraries in light of what we've learnt from deploying unikernels with MirageOS. We have paid particular attention to memory usage, to avoiding known CVEs from our previous implementations (as we are also part of the OCaml security team), and also to offering an alternative API that does not systematically rely on functors. The approach is still experimental, as we need to consolidate this new ecosystem across several layers, but we are firmly convinced (based on what we've observed in our deployed unikernels) that these new implementations are significantly better than what we used in the past. ### To deploy unikernels The other side of unikernels is deployment. Indeed, it is not just a matter of developing unikernels (and making their development easier) but also of deploying and using them. Our main objective remains to replace existing services with unikernels (name servers, websites, time servers, etc.), and the way to compete with existing infrastructure is to actively deploy and use our unikernels. That is why we have developed two projects: - [Albatross][albatross], an OCaml service for launching unikernels - [Aussi][aussi], an OCI runtime for Solo5 We mainly use Albatross in conjunction with our infrastructure for verifyin= g the reproducibility of our unikernels: [builds.robur.coop][builds.robur.coo= p ]. In this way, we can trace the dependencies of the unikernels - particularly their CVEs - and ensure supply-chain security. Next comes deployment, and we are therefore seeking to integrate our unikernels into existing infrastructure and provide ways of monitoring them, in particular using [InfluxDB][influxdb], [Telegraf][telegraf] and [Grafana][grafana]. This is how we are able to offer services such as (note that some haven't yet been ported to `mkernel`/`mnet`, but will be soon): - simple websites such as our https://blog.robur.coop/ (using [`unipi`][unipi] or [`immuable`][immuable]) - domain name management for domains such as `robur.coop`, `reyn.ir` or `din.osau.re` (via our [primary][dns-primary-git] DNS server and [secondary][mnet-secondary] server) - a VPN service, whether using [MirageVPN][MirageVPN] or [Zostera][zostera] - a time server (using [Chaos][chaos]): https://chaos.osau.re/ - a [CalDAV][caldav] calendar system - [a mailing list][mailingl.st] using the [`ptt`][ptt] project - a TLS termination proxy such as [`tlstunnel`][tlstunnel] or [`contruno`][contruno] (used by sherlocode.com) - and many more! It is therefore through actual use that we improve our unikernels and the libraries that depend on them. That is why part of our tutorial also focuses on deploying unikernels, so that you can use them and help us with your feedback. Finally, we are also proposing a project called [Mollymawk][mollymawk], designed to simplify the deployment of unikernels via a web interface, so that, in future, we can offer access to our infrastructure to anyone who wishes t= o use it (and we would like to thank @kit-ty-kate for their various attempts)= . ## About us Finally, none of this would be possible without our co-operative and the way we organise our work. You can view the details of our finances [here][robur-finance]. We accept donations and have recently secured fundin= g from NLnet. Private companies such as [Ahrefs][ahrefs] and [Tarides][tarides] also sponsor our work. We also have partnerships with [OCamlPro][ocamlpro] and the [OCaml Foundation][ocf]. And we contribute to the OCaml ecosystem on a daily basis by working with individuals and companies. You can find more details on [our website][robur.coop]. We would like to emphasise that it is thanks to our structure (that of an association) that we are able to carry out this work, and we would like to thank our sponsors. ## Unikernels and MirageOS Enthusiasts may wonder what the advantage of our approach is compared to MirageOS, a unikernel project that remains active thanks to our maintenance work. Our approach is characterised by five points that we have identified as glass ceilings to the adoption of unikernels: - the first concerns the use of [`ocaml-cstruct`][ocaml-cstruct]. The fundamental issue remains the use of `bigarray` as _buffer_ instead of `bytes`/`string`. Our experience whilst developing [MirageVPN][miragevpn] has shown us that using `cstruct` as a systematic library for the _buffer_ concept Across our entire ecosystem was our biggest **penalty** in terms of throughput for our unikernel. This is why we decided not only to develop [`bstr`][bstr] and [`slice`][bstr], but also to rewrite the majority of our libraries by replacing `cstruct` with `bytes`/`string` (this was the case for [`ocaml-tls`][ocaml-tls-pr], [`mirage-crypto`][mirage-crypto-pr], [`ocaml-dns`][ocaml-dns-pr] and, more recently, [`awa-ssh`][awa-ssh-pr] and [`utcp`][utcp-pr]). The conclusion is quite simple: it is not a question of stopping using bigarray, but rather of not making their use systematic in our aPIs. - the second point concerns the use of functors to express the devices required by the unikernel. The approach of reusing interfaces to inject specific implementations that concretize these devices via functors may seem appealing, but the maintenance cost of such an ecosystem=E2=80=94constrai= ned by interfaces that are no longer really up to date with new concepts=E2=80= =94has led us into [absurd situations][absurd] whenever we've needed to develop more specific unikernels tailored to our requirements. Once again, the rule is not to stop using functors, but not to make their use systematic. - the third point concerns the compilation of unikernels. MirageOS relies on a workaround that, even today, integrates very poorly with `dune`; this can be defined as: _multi-stage compilation_, where a code-generation phase is required depending on the desired _target_. This way of structuring the workflow with a set of dependencies dictated by the tool explicitly restricts the developer in what they wish to do and how they wish to do it. Althoug= h there are constraints on compiling a unikernel (such as not using the `Unix` module), our cooperative has decided to provide **informative** (and not prescriptive) tools that assist (but do not force) the user in designing their unikernel (furthermore, we are also delighted to introduce [`unic`][unic] and [`mfetch`][mfetch]). The key point of our new approach is to ensure that it is the user who has the final say, rather than the tool (in this case, `mirage`), in the development of unikernels. It is very intricate on what the `mirage` tool does, including generation of functor applications and some initialization stubs, as well as opam version constraints (since the functors and initialization functions may change i= n new opam packages). The `mirage` tool has a closed world assumption, and it is hard to use a package not known by `mirage` - it is as well very hard to use `js_of_ocaml` in a `mirage` unikernel. - the fourth point concerns the maintenance of this ecosystem, and specifically the maintenance of the tools and libraries on which MirageOS relies. Furthermore, we have experienced some disappointments with `opam-monorepo`, and we are finding, day by day, that it is becoming increasingly difficult to update `mirage-tcpip` in line with OCaml 5. Our involvement in the OCaml security team has also led us to wish to deprecate certain libraries due to a lack of maintenance. We are therefore refocusing our ecosystem on what ou= r co-operative produces and maintains. - Finally, the last point concerns our work with the community, which remains unchanged despite the emergence of AI. We have observed a certain abusive use of AI to solve non-existent problems relating to unikernels, which, in ou= r view, undermines our credibility regarding the security, maintenance and quality of our software. In this regard, we are trying to distance ourselves from those who prefer _vibe-coding_ rather than deployment. This approach is reflected in our use of the [AGPL][agpl] as our licence (whilst offering the option of dual licensing) and a [POLICY][policy] regarding the use of AI. All of this has led us to propose MirageOS 5, which represents a fundamenta= l departure from the factors that characterised the failure of MirageOS 4 (fo= r which I was the release manager). It is therefore, having acknowledged this defeat (and analysed it), that we are proposing a new approach to creating and deploying unikernels: [uniker.nl][uniker.nl]. As regards the projects associated with the MirageOS project, we will, of course, continue to maintain some of them, whilst at the same time offering more up-to-date solutions to those who use some of our libraries. We would also be delighted to help anyone wishing to migrate to our new libraries and tools; we are (as we always have been) available to assist. [unic]: https://github.com/robur-coop/unic [mfetch]: https://github.com/robur-coop/mfetch [agpl]: https://www.gnu.org/licenses/agpl-3.0.en.html [policy]: https://github.com/Solo5/solo5/blob/main/AI.md [ocaml-cstruct]: https://github.com/mirage/ocaml-cstruct [miragevpn]: https://github.com/robur-coop/miragevpn [tarides]: https://tarides.com/ [ahrefs]: https://ahrefs.com/ [robur-finance]: https://blog.robur.coop/articles/finances.html [mollymawk]: https://mollymawk.robur.coop/ [bstr]: https://github.com/robur-coop/bstr [immuable]: https://github.com/dinosaure/immuable [uniker.nl]: https://uniker.nl/ [builds.robur.coop]: https://builds.robur.coop [zostera]: https://github.com/robur-coop/zostera [workshop]: https://ocaml.org/ocaml-workshop-2026 [slides]: https://docs.google.com/presentation/d/1bOXJAPEEjPBx_8i0frThKhLpHd8C7-EPRcz= EQjvz6JU/edit?slide=3Did.g3f7268904c5_0_1#slide=3Did.g3f7268904c5_0_1 [uniker.nl-tutorial]: https://uniker.nl/introduction/ [yocaml]: https://yocaml.github.io/tutorial/index.html [blog-robur]: https://blog.robur.coop/ [miou-announce]: https://discuss.ocaml.org/t/ann-miou-a-simple-scheduler-for-ocaml-5/12963 [sans-io]: https://discuss.ocaml.org/t/on-concurrency-models/15899/13 [sans-io-2]: https://discuss.ocaml.org/t/why-ocsigen-is-staying-on-lwt-for-now/18318/27 [digestif]: https://github.com/mirage/digestif [mnet]: https://discuss.ocaml.org/t/ann-mnet-a-new-tcp-ip-stack-for-unikernels-in-o= caml/17851 [mirage-crypto]: https://github.com/mirage/mirage-crypto [solo5]: https://github.com/solo5/solo5 [mkernel]: https://github.com/robur-coop/mkernel [lwt]: https://github.com/ocsigen/lwt [tlstunnel]: https://github.com/robur-coop/tlstunnel [contruno]: https://github.com/robur-coop/contruno [mailingl.st]: https://mailingl.st [ptt]: https://github.com/robur-coop/ptt [albatross]: https://github.com/robur-coop/albatross [aussi]: https://github.com/robur-coop/aussi [chaos]: https://github.com/robur-coop/chaos [unipi]: https://github.com/robur-coop/unipi [mnet]: https://github.com/robur-coop/mnet [ocaml-solo5]: https://github.com/mirage/ocaml-solo5 [utcp]: https://github.com/robur-coop/utcp [codept]: https://github.com/Octachron/codept [mnet-announce]: https://discuss.ocaml.org/t/ann-mnet-a-new-tcp-ip-stack-for-unikernels-in-o= caml/17851 [mhttp]: https://github.com/robur-coop/mhttp [mfat]: https://github.com/robur-coop/mfat [vifu]: https://github.com/robur-coop/vif [msendmail]: https://github.com/robur-coop/colombe [dns-primary-git]: https://github.com/robur-coop/dns-primary-git/ [mnet-secondary]: https://git.robur.coop/robur/dns-secondary/ [uniker.nl-repo]: https://github.com/robur-coop/uniker.nl [orb]: https://github.com/robur-coop/orb [grafana]: https://grafana.com/ [influxdb]: https://www.influxdata.com/ [telegraf]: https://www.influxdata.com/time-series-platform/telegraf/ [ocamlpro]: https://ocamlpro.com [ocf]: https://ocaml-sf.org/ [robur.coop]: https://robur.coop/ [ocaml-tls-pr]: https://github.com/mirleft/ocaml-tls/pull/497 [mirage-crypto-pr]: https://github.com/mirage/mirage-crypto/pull/214 [ocaml-dns-pr]: https://github.com/mirage/ocaml-dns/pull/351 [awa-ssh-pr]: https://github.com/mirage/awa-ssh/pull/85 [utcp-pr]: https://github.com/robur-coop/utcp/pull/55 [absurd]: https://github.com/robur-coop/dnsvizor/blob/83b32596c4a08c080067e1cd36fe578= 8b90cdd78/unikernel.ml#L610-L631 [caldav]: https://github.com/robur-coop/caldav --=20 Romain Calascibetta - http://din.osau.re/ --00000000000077953a065e476c62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a cross-post in Markdown format that you= can find here: https://discuss.ocaml.org/t/ann-uniker-nl-unikernels-i= n-ocaml/18625

We are delighted to announce the launch of our new= website:
[uniker.nl][uniker.nl]. This website embodies our new approach to devel= oping
unikernels with OCaml 5. It offers a new way of developing unikern= els and now
places just as much emphasis on the deployment and use of un= ikernels. The
website features a comprehensive [tutorial][uniker.nl-tuto= rial] and resources
to help you get to grips with our new ecosystem, pro= viding a _first entry
point_ for anyone interested in unikernels in OCam= l.

The content of this site is available [here][uniker.nl-repo], is = powered by the
excellent [YOCaml][yocaml] project, and is deployed using= our
[immuable][immuable] unikernel.

## Our new ecosystem

= We were able to present our new workflow at the [OCaml Workshop 2026][works= hop]
([slides][slides]) and our approach can be summarised in two main p= oints:
- the development of unikernels
- the deployment of unikernels= and their uses

### To develop unikernels

Our co-operative ha= s been developing unikernels for quite a few years now. [Our
blog][blog-= robur] showcases some of the ones we use for our infrastructure.
Based o= n our experience, we are well aware of the constraints and limitations
o= f what we can achieve when it comes to developing an application in the for= m
of a unikernel. The best-known constraint we have accepted is not to r= equire
the POSIX interface (nor to attempt to replicate it) in terms of = protocols and
formats. One of the rules still adhered to today is, among= st other things, [not
to depend on I/O or a scheduler][sans-io]<sup&g= t;[1][sans-io-2]</sup> when
providing implementations.

Buil= ding on this experience, we have been able to develop protocols and formats=
that are currently being used by others in contexts other than unikerne= ls.

However, we have also seen the limits of what we can achieve, pa= rticularly with
what MirageOS currently offers. With this in mind, and u= pon further reflection
on the constraints we face when developing uniker= nels (particularly regarding
cross-compilation), we have decided to stru= cture the development of unikernels
using two tools: [`unic`][unic] and = [`mfetch`][mfetch].

#### [`unic`][unic]: how to infer dependencies a= nd _vendor_ them

One constraint we face with unikernels is the need = to recompile C files with
specific options so that they do not depend on= what already exists on the host
system. The approach taken by MirageOS = 3 was to distribute the result of this
specific compilation within libra= ries that contain C stubs (such as
[`digestif`][digestif] or [`mirage-cr= ypto`][mirage-crypto]). The problem is
that we were forcing users of the= se libraries to install
[`ocaml-solo5`][ocaml-solo5] in order to obtain = a compilation environment for C
files specific to [Solo5][solo5], our co= re component for producing unikernels.

MirageOS 4 then arrived with = `dune` and its contexts, allowing us to achieve a
consistent compilation= environment for C files. However, this approach
introduced new a constr= aint: all dependencies of our unikernels had to use
`dune`, which is **l= egitimately** not the case in the OCaml ecosystem.

It is for this re= ason that we decided to refine the need to recompile some of
our librari= es a little further and, finally, to be able to capitalise on a key
adva= ntage of [`ocaml-solo5`][ocaml-solo5], namely that compiling OCaml fileswith this compiler produces exactly the same result as if you were using y= our
host OCaml compiler: in other words, and as has been the case from t= he
beginning, we strictly only need to cross-compile the C files.
It is therefore at the intersection of these two features (only needing to=
cross-compile the C files and being able to reuse libraries written in = pure
OCaml and compiled with the host compiler) that we can offer users = the ability
to write this sort of code without involving any maintenance= work on libraries
that do not use `dune` and without necessarily having= to recompile everything:

```shell
$ opam install unic
$ cat &= gt;main.ml<<EOF
> open Digestif<= br>
> let () =3D Mkernel.run [] @@ fun () ->
> =C2=A0 Fmt.pr= "%a\n%!" SHA1.pp (SHA1.digest_string "Hello World!")> EOF
$ unic infer -r .
Module Digestif is provided by several o= camlfind packages:
=C2=A0 [0] digestif.c
=C2=A0 [1] digestif.ocamlPick one [0-1]: 0
digestif
mkernel
$ opam source digestif
$ op= am source mkernel
$ dune build
$ solo5-hvt -- _build/solo5/main.exe -= -solo5:quiet
2ef7bde608ce5404e97d5f042f95f89f1c232871Solo5
```
`unic` is therefore a tool capable of inferring the dependencies of an OCa= ml
project without using a specific build system, and of calculating wha= t needs to
be cross-compiled (in this case `digestif` and `mkernel` but = not `fmt`) to
produce a unikernel. The project serves our purpose first = and foremost, but it
is worth noting that it can also be useful when com= piling statically linked
executables.

This tool offers a whole ra= nge of sub-tools for analysing META files, viewing
an artefact from diff= erent perspectives (its module name, its `ocamlfind`
package name and it= s OPAM package name) or analysing OCaml artefacts (such as
`*.cmxa` file= s).

We would particularly like to thank @Octachron for his [`codept`= ][codept]
project (on which `unic` is based) and for working with us to = improve it.

### [`mfetch`][mfetch]: how to vendor dependencies
Having identified more precisely which dependencies need to be cross-comp= iled,
we now need to download these dependencies. Although `opam source`= does the job
very well, we wanted a tool that could download the source= code from various
types of source, such as:
- from a _tarball_, as i= s usually the case
- but also from a Git repository
- or even from a = specific location on your file system

That is why we developed `mfet= ch`, which allows you to download software
sources based on information = provided by OPAM or the user, and to create a
`vendors` folder containin= g all these sources.

```shell
$ unic infer -r . -o _mfetch
$ m= fetch --with-dune-file
=C2=A0digestif =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =E2=94=82=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96= =88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88= =E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=94=82 =C2=A0 =C2=A03.1 MiB= / =C2=A0 =C2=A03.1 MiB =C2=A0 =C2=A05.9 MiB/s
=C2=A0mkernel =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=94=82=E2=96=88=E2= =96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96= =88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88= =E2=94=82 =C2=A0 37.3 KiB / =C2=A0 37.3 KiB =C2=A0 =C2=A03.4 MiB/s

= digestif =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ok
mkernel =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ok
$ dune build
```
`mfetch` also allows you to check whether you have modified any of th= e source
files (for a bug fix) or to generate a `*.locked` file so that = you can then
verify the reproducibility of your unikernel using our othe= r tool [`orb`][orb].
The tool itself is not revolutionary, but it helps = to streamline the workflow.

```shell
$ mfetch status
digestif = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ok
mkernel =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ok
$ mfetch lock
2 sources l= ocked into _mfetch.locked
```

#### Libraries for OCaml 5

O= ur new workflow now uses OCaml 5. As well as updating the basic buildingblocks required to produce unikernels with OCaml 5, we have also developed= a
series of libraries that primarily enable us to take advantage of eff= ects.
Furthermore, over the past several years we have developed:
- [= Miou][miou-announce], our scheduler for OCaml 5
- [`mkernel`][mkernel], = a derivative of our Miou scheduler designed to handle
=C2=A0 the I/O pro= vided by Solo5
- [`mnet`][mnet-announce], a reimplementation of the TCP/= IP stack (using
=C2=A0 [`utcp`][utcp]) in OCaml with effects
- and pl= enty of other libraries such as [`mhttp`][mhttp],
=C2=A0 [`msendmail`][m= sendmail], [`mfat`][mfat], [`vifu`][vifu], etc.

These libraries, cur= rently used by some of our deployed unikernels, allow us to
offer develo= pers a _direct-style_ approach to implementing their unikernels.

But= what is key to take away from this emerging ecosystem is the retrospective=
analysis of past projects to ensure we do not repeat the same mistakes.= We very
quickly realised that it could be very difficult to migrate exi= sting libraries
using [`lwt`][lwt] (the MirageOS scheduler) to Miou (or = any other scheduler
using effects). We therefore took the opportunity no= t only to propose a
_direct-style_ approach using Miou, but also to reth= ink the implementation of
our libraries in light of what we've learn= t from deploying unikernels with
MirageOS. We have paid particular atten= tion to memory usage, to avoiding known
CVEs from our previous implement= ations (as we are also part of the OCaml
security team), and also to off= ering an alternative API that does not
systematically rely on functors.<= /div>

The approach is still experimental, as we need to = consolidate this new
ecosystem across several layers, but we are firmly = convinced (based on what
we've observed in our deployed unikernels) = that these new implementations are
significantly better than what we use= d in the past.

### To deploy unikernels

The other side of uni= kernels is deployment. Indeed, it is not just a matter of
developing uni= kernels (and making their development easier) but also of
deploying and = using them. Our main objective remains to replace existing
services with= unikernels (name servers, websites, time servers, etc.), and the
way to= compete with existing infrastructure is to actively deploy and use our
= unikernels.

That is why we have developed two projects:
- [Albatr= oss][albatross], an OCaml service for launching unikernels
- [Aussi][aus= si], an OCI runtime for Solo5

We mainly use Albatross in conjunction= with our infrastructure for verifying
the reproducibility of our uniker= nels: [builds.robur.coop][builds.robur.coop].
In this way, we ca= n trace the dependencies of the unikernels - particularly
their CVEs - a= nd ensure supply-chain security.

Next comes deployment, and we are t= herefore seeking to integrate our unikernels
into existing infrastructur= e and provide ways of monitoring them, in particular
using [InfluxDB][in= fluxdb], [Telegraf][telegraf] and [Grafana][grafana].

This is how we= are able to offer services such as (note that some haven't yet
been ported to `mkernel`/`mnet`, but will be soon):
- simple websites= such as our https://blog.robur.coop/<= /a> (using [`unipi`][unipi]
=C2=A0 or [`immuable`][immuable])
- domai= n name management for domains such as `robur.= coop`, `reyn.ir` or
=C2=A0 `din.osau.re` (via our [primary][dns-primary-git= ] DNS server and
=C2=A0 [secondary][mnet-secondary] server)
- a VPN s= ervice, whether using [MirageVPN][MirageVPN] or [Zostera][zostera]
- a t= ime server (using [Chaos][chaos]): https= ://chaos.osau.re/
- a [CalDAV][caldav] calendar system
- [a maili= ng list][mailingl.st] using the [`ptt`][= ptt] project
- a TLS termination proxy such as [`tlstunnel`][tlstunnel] = or
=C2=A0 [`contruno`][contruno] (used by sherlocode.com)
- and many more!

It is therefore through = actual use that we improve our unikernels and the
libraries that depend = on them. That is why part of our tutorial also focuses on
deploying unik= ernels, so that you can use them and help us with your feedback.

Fin= ally, we are also proposing a project called [Mollymawk][mollymawk],
des= igned to simplify the deployment of unikernels via a web interface, so that= ,
in future, we can offer access to our infrastructure to anyone who wis= hes to
use it (and we would like to thank @kit-ty-kate for their various= attempts).

## About us

Finally, none of this would be possib= le without our co-operative and the way we
organise our work. You can vi= ew the details of our finances
[here][robur-finance]. We accept donation= s and have recently secured funding
from NLnet. Private companies such a= s [Ahrefs][ahrefs] and [Tarides][tarides]
also sponsor our work. We also= have partnerships with [OCamlPro][ocamlpro] and
the [OCaml Foundation][= ocf]. And we contribute to the OCaml ecosystem on a
daily basis by worki= ng with individuals and companies.

You can find more details on [our= website][robur.coop]. We would like toemphasise that it is thanks to our structure (that of an association) tha= t we
are able to carry out this work, and we would like to thank our spo= nsors.

## Unikernels and MirageOS

Enthusias= ts may wonder what the advantage of our approach is compared to
MirageOS= , a unikernel project that remains active thanks to our maintenance
work= . Our approach is characterised by five points that we have identified asglass ceilings to the adoption of unikernels:
- the first concerns the= use of [`ocaml-cstruct`][ocaml-cstruct]. The
=C2=A0 fundamental issue r= emains the use of `bigarray` as _buffer_ instead of
=C2=A0 `bytes`/`stri= ng`. Our experience whilst developing [MirageVPN][miragevpn] has
=C2=A0 = shown us that using `cstruct` as a systematic library for the _buffer_
= =C2=A0 concept Across our entire ecosystem was our biggest **penalty** in t= erms of
=C2=A0 throughput for our unikernel. This is why we decided not = only to develop
=C2=A0 [`bstr`][bstr] and [`slice`][bstr], but also to r= ewrite the majority of our
=C2=A0 libraries by replacing `cstruct` with = `bytes`/`string` (this was the case for
=C2=A0 [`ocaml-tls`][ocaml-tls-p= r], [`mirage-crypto`][mirage-crypto-pr],
=C2=A0 [`ocaml-dns`][ocaml-dns-= pr] and, more recently, [`awa-ssh`][awa-ssh-pr] and
=C2=A0 [`utcp`][utcp= -pr]). The conclusion is quite simple: it is not a question of
=C2=A0 st= opping using bigarray, but rather of not making their use systematic in our=
=C2=A0 aPIs.
- the second point concerns the use of functors to expr= ess the devices required
=C2=A0 by the unikernel. The approach of reusin= g interfaces to inject specific
=C2=A0 implementations that concretize t= hese devices via functors may seem
=C2=A0 appealing, but the maintenance= cost of such an ecosystem=E2=80=94constrained by
=C2=A0 interfaces that= are no longer really up to date with new concepts=E2=80=94has led us
= =C2=A0 into [absurd situations][absurd] whenever we've needed to develo= p more
=C2=A0 specific unikernels tailored to our requirements. Once aga= in, the rule is not
=C2=A0 to stop using functors, but not to make their= use systematic.
- the third point concerns the compilation of unikernel= s. MirageOS relies on a
=C2=A0 workaround that, even today, integrates v= ery poorly with `dune`; this can be
=C2=A0 defined as: _multi-stage comp= ilation_, where a code-generation phase is
=C2=A0 required depending on = the desired _target_. This way of structuring the
=C2=A0 workflow with a= set of dependencies dictated by the tool explicitly restricts
=C2=A0 th= e developer in what they wish to do and how they wish to do it. Although=C2=A0 there are constraints on compiling a unikernel (such as not using t= he `Unix`
=C2=A0 module), our cooperative has decided to provide **infor= mative** (and not
=C2=A0 prescriptive) tools that assist (but do not for= ce) the user in designing
=C2=A0 their unikernel (furthermore, we are al= so delighted to introduce
=C2=A0 [`unic`][unic] and [`mfetch`][mfetch]).= The key point of our new approach is
=C2=A0 to ensure that it is the us= er who has the final say, rather than the tool (in
=C2=A0 this case, `mi= rage`), in the development of unikernels.
=C2=A0
=C2=A0 It is very i= ntricate on what the `mirage` tool does, including generation of
=C2=A0 = functor applications and some initialization stubs, as well as opam version=
=C2=A0 constraints (since the functors and initialization functions may= change in
=C2=A0 new opam packages). The `mirage` tool has a closed wor= ld assumption, and it
=C2=A0 is hard to use a package not known by `mira= ge` - it is as well very hard to
=C2=A0 use `js_of_ocaml` in a `mirage` = unikernel.
- the fourth point concerns the maintenance of this ecosystem= , and specifically
=C2=A0 the maintenance of the tools and libraries on = which MirageOS relies.
=C2=A0 Furthermore, we have experienced some disa= ppointments with `opam-monorepo`,
=C2=A0 and we are finding, day by day,= that it is becoming increasingly difficult to
=C2=A0 update `mirage-tcp= ip` in line with OCaml 5. Our involvement in the OCaml
=C2=A0 security t= eam has also led us to wish to deprecate certain libraries due to a
=C2= =A0 lack of maintenance. We are therefore refocusing our ecosystem on what = our
=C2=A0 co-operative produces and maintains.
- Finally, the last p= oint concerns our work with the community, which remains
=C2=A0 unchange= d despite the emergence of AI. We have observed a certain abusive use
= =C2=A0 of AI to solve non-existent problems relating to unikernels, which, = in our
=C2=A0 view, undermines our credibility regarding the security, m= aintenance and
=C2=A0 quality of our software. In this regard, we are tr= ying to distance ourselves
=C2=A0 from those who prefer _vibe-coding_ ra= ther than deployment. This approach is
=C2=A0 reflected in our use of th= e [AGPL][agpl] as our licence (whilst offering the
=C2=A0 option of dual= licensing) and a [POLICY][policy] regarding the use of AI.

All of t= his has led us to propose MirageOS 5, which represents a fundamental
dep= arture from the factors that characterised the failure of MirageOS 4 (forwhich I was the release manager). It is therefore, having acknowledged th= is
defeat (and analysed it), that we are proposing a new approach to cre= ating and
deploying unikernels: [uniker.nl<= /a>][uniker.nl].

As regards the pro= jects associated with the MirageOS project, we will, of
course, continue= to maintain some of them, whilst at the same time offering
more up-to-d= ate solutions to those who use some of our libraries. We would also
be d= elighted to help anyone wishing to migrate to our new libraries and tools;<= br>we are (as we always have been) available to assist.

[unic]: https://github= .com/robur-coop/unic
[mfetch]: https://github.com/robur-coop/mfetch
[agpl]: https://www.gnu.org/licenses= /agpl-3.0.en.html
[policy]: https://github.com/Solo5/solo5/blob/main/AI.md
[o= caml-cstruct]: https://= github.com/mirage/ocaml-cstruct
[miragevpn]: https://github.com/robur-coop/miragevpn[tarides]: https://tarides.com/
[a= hrefs]: https://ahrefs.com/
[robur-f= inance]: https:/= /blog.robur.coop/articles/finances.html
[mollymawk]: https://mollymawk.robur.coop/
[bstr]: https://github.com/robur-coop/b= str
[immuable]: ht= tps://github.com/dinosaure/immuable
[un= iker.nl]: https://uniker.nl/
[builds.robur.coop]: https://builds.robur.coop
[zostera]: https://github.com/robur-coop/zoste= ra
[workshop]: htt= ps://ocaml.org/ocaml-workshop-2026
[slides]: https://docs.goo= gle.com/presentation/d/1bOXJAPEEjPBx_8i0frThKhLpHd8C7-EPRczEQjvz6JU/edit?sl= ide=3Did.g3f7268904c5_0_1#slide=3Did.g3f7268904c5_0_1
[uniker.nl-tut= orial]: https://uniker.nl/intro= duction/
[yocaml]: https://yocaml.github.io/tutorial/index.html
[blog-robur]: <= a href=3D"https://blog.robur.coop/">https://blog.robur.coop/
[miou-a= nnounce]: https://discuss.ocaml.org/t/ann-miou-a-simple-schedule= r-for-ocaml-5/12963
[sans-io]: https://discuss.ocaml.org/t/on-concurrenc= y-models/15899/13
[sans-io-2]: https://discuss.ocaml.org= /t/why-ocsigen-is-staying-on-lwt-for-now/18318/27
[digestif]: https://github.com/mirage/digestif=
[mnet]: https://discuss.ocaml.org/t/ann-mnet= -a-new-tcp-ip-stack-for-unikernels-in-ocaml/17851
[mirage-crypto]: <= a href=3D"https://github.com/mirage/mirage-crypto">https://github.com/mirag= e/mirage-crypto
[solo5]: = https://github.com/solo5/solo5
[mkernel]: https://github.com/robur-coop/mkernel
[lwt]:= https://github.com/ocsigen/lwt<= /a>
[tlstunnel]: htt= ps://github.com/robur-coop/tlstunnel
[contruno]: https://github.com/robur-coop/contruno<= br>[mailingl.st]: https://mailingl.st
[ptt]: https://github.com/robur-coop/ptt
[albatross]: https://github.com/robur-coop= /albatross
[aussi]: = https://github.com/robur-coop/aussi
[chaos]: https://github.com/robur-coop/chaos
[unipi]= : https://github.com/robur-= coop/unipi
[mnet]: ht= tps://github.com/robur-coop/mnet
[ocaml-solo5]: https://github.com/mirage/ocaml-solo5
= [utcp]: https://github.com/r= obur-coop/utcp
[codept]: https://github.com/Octachron/codept
[mnet-announce]: https://discuss.ocaml.org/t/ann-mnet-a-new-tcp-ip-stack-for-un= ikernels-in-ocaml/17851
[mhttp]: https://github.com/robur-coop/mhttp
[mfat]: https://github.com/robur-coop/mfat<= br>[vifu]: https://github.com= /robur-coop/vif
[msendmail]: https://github.com/robur-coop/colombe
[dns-primary-git]: = https://github.c= om/robur-coop/dns-primary-git/
[mnet-secondary]: https://git.robur.coop/robur/dns-secon= dary/
[uniker.nl-repo]: https://github.com/robur-coop/uniker.nl
[orb]: https://github.com/robur-coop/orb
[= grafana]: https://grafana.com/
[inf= luxdb]: https://www.influxdata.com/=
[telegraf]: https://www.influxdata.com/time-series-platform/telegraf/
[ocamlpro]: https://ocamlpro.com<= br>[ocf]: https://ocaml-sf.org/
[<= a href=3D"http://robur.coop">robur.coop]: https://robur.coop/
[ocaml-tls-pr]: https://github.com/mirleft/ocaml-tls/pull/497<= /a>
[mirage-crypto-pr]: https://github.com/mirage/mirage-crypto/pull/214
[ocaml= -dns-pr]: https://= github.com/mirage/ocaml-dns/pull/351
[awa-ssh-pr]: https://github.com/mirage/awa-ssh/pull= /85
[utcp-pr]: https://github.com/robur-coop/utcp/pull/55
[absurd]: https://github.com/robur-coop/dnsvizor/blob= /83b32596c4a08c080067e1cd36fe5788b90cdd78/unikernel.ml#L610-L631
[ca= ldav]: https://github.com/= robur-coop/caldav

--
Romain Calascibetta - http://din.osau.re/
--00000000000077953a065e476c62--