Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/2023-10-16.html",
3 "title": "16 Oct 2023",
4 "link": "https://ryan.freumh.org/2023-10-16.html",
5 "updated": "2023-10-16T00:00:00",
6 "published": "2023-10-16T00:00:00",
7 "summary": "<div>\n <span> Previous: <a href=\"2023-10-09.html\"> 9 Oct 2023</a> </span>\n <span> Next: <a href=\"2023-10-23.html\">23 Oct 2023</a> </span>\n </div>\n \n \n\n <h2>HotNets</h2>\n<ul>\n<li>Converted the SNS paper to the ACM final format. Spent way to long\nfiguring out how to make the paper open access. While trying to figure\nthis out I spoke to Jon, Chris, Ardwin, Justas, Sadiq, Helen, and Mort.\nMort explained the difference between the copyright, licensing\npublishing rights, and open access. In the end, we had to use our\ninstitutional email addresses to have the ACM’s open access policy kick\nin.</li>\n<li>Addressed Magnus’ comments on the paper, and fixed some\ncitations.</li>\n<li>Pulled the discussion into the introduction.</li>\n</ul>\n<h2>Hibernia</h2>\n<p><span>Had an idea regarding the <a href=\"./2023-10-09.html#energy\">energy</a> saving ‘wake-up’ device: the\nnetwork infrastructure has to be running anyway, so why not push this\nfunctionality into the router, which are mostly running Linux now\nanyway. We could implement this as a OCaml <a href=\"https://github.com/RyanGibb/aeon\">AEON</a> amalgamation on top of\nOpenWRT (or NixOS)… but could we go all the way and implement this as a\nMirageOS unikernel (for maximum power savings). Could the <a href=\"https://github.com/mirage/mirage-tcpip\">MirageOS TCP/IP stack</a>\nbe used as a router for this unikernel? The <a href=\"https://gitlab.developers.cam.ac.uk/cst/eeg/papers/pre-2019/-/blob/master/unikernel-router/unirouter.pdf\">unikernel\nrouter</a> from Magnus would seem to suggest so!</span></p>\n<h2><code>shark</code> Reading Group</h2>\n<p><span>On <a href=\"https://doi.org/10.1145/269005.266669\">DIFC</a> and <a href=\"https://doi.org/10.1145/2018396.2018419\">HiStar</a>.</span></p>\n<p><img src=\"./images/2023-10-20-reading-group.svg\"></p>\n<h2>Teaching</h2>\n<ul>\n<li>TA’d L50. One of my students was telling me about Fedora’s new\nimmutable operating systems that uses OSTree (like git for\nbinaries).</li>\n<li>Marked and supervised all day for Distributed & Current Systems\nfor Pembroke. I learnt how async/sync FSM semi-coupled/de-coupled\nproducts worked in the first supervision, and in the second I did more\nteaching than learning.</li>\n</ul>\n<h2>Self-hosting</h2>\n<p><span>I mentioned that I didn’t set up a\nPeerTube instance as my server doesn’t have enough storage, and Anil\nmentioned that he as some SSD’s lying around that we could repurpose\nwith a USB/SATA interface host hosting on the Pi in my\noffice.</span></p>\n<h2>Opam & Nix</h2>\n<p><span>I’ve implemented Spencer’s suggestion of\nsolving for a single instance of Nixpkgs for the Opam Nix backend for\nuse in the OCaml CI in a <a href=\"https://github.com/RyanGibb/opam-lang-repo-nix\">prototype</a>.</span></p>\n<p><span>I do so by creating a <code>nixpkgs</code>\npackage version for each Nixpkgs revision, that conflicts with other\nversions of itself. When we don’t care about this (when we’re not\nlinking the provided libraries together), such as providing a rust\ncompiler and python interpreter with versions from different instance of\nNixpkgs, I think this could be made optional with a custom variable\n& filter.</span></p>\n<p><span>The next step would be to generate this\nfrom the Nixpkgs repository itself. Currently I’m just using a few\nmanually cherry picked examples in a prototype: <a href=\"https://github.com/RyanGibb/opam-lang-repo-nix\">opam-lang-repo-nix</a>.</span></p>",
8 "content": "<div>\n <span> Previous: <a href=\"2023-10-09.html\"> 9 Oct 2023</a> </span>\n <span> Next: <a href=\"2023-10-23.html\">23 Oct 2023</a> </span>\n </div>\n \n \n\n <h2>HotNets</h2>\n<ul>\n<li>Converted the SNS paper to the ACM final format. Spent way to long\nfiguring out how to make the paper open access. While trying to figure\nthis out I spoke to Jon, Chris, Ardwin, Justas, Sadiq, Helen, and Mort.\nMort explained the difference between the copyright, licensing\npublishing rights, and open access. In the end, we had to use our\ninstitutional email addresses to have the ACM’s open access policy kick\nin.</li>\n<li>Addressed Magnus’ comments on the paper, and fixed some\ncitations.</li>\n<li>Pulled the discussion into the introduction.</li>\n</ul>\n<h2>Hibernia</h2>\n<p><span>Had an idea regarding the <a href=\"./2023-10-09.html#energy\">energy</a> saving ‘wake-up’ device: the\nnetwork infrastructure has to be running anyway, so why not push this\nfunctionality into the router, which are mostly running Linux now\nanyway. We could implement this as a OCaml <a href=\"https://github.com/RyanGibb/aeon\">AEON</a> amalgamation on top of\nOpenWRT (or NixOS)… but could we go all the way and implement this as a\nMirageOS unikernel (for maximum power savings). Could the <a href=\"https://github.com/mirage/mirage-tcpip\">MirageOS TCP/IP stack</a>\nbe used as a router for this unikernel? The <a href=\"https://gitlab.developers.cam.ac.uk/cst/eeg/papers/pre-2019/-/blob/master/unikernel-router/unirouter.pdf\">unikernel\nrouter</a> from Magnus would seem to suggest so!</span></p>\n<h2><code>shark</code> Reading Group</h2>\n<p><span>On <a href=\"https://doi.org/10.1145/269005.266669\">DIFC</a> and <a href=\"https://doi.org/10.1145/2018396.2018419\">HiStar</a>.</span></p>\n<p><img src=\"./images/2023-10-20-reading-group.svg\"></p>\n<h2>Teaching</h2>\n<ul>\n<li>TA’d L50. One of my students was telling me about Fedora’s new\nimmutable operating systems that uses OSTree (like git for\nbinaries).</li>\n<li>Marked and supervised all day for Distributed & Current Systems\nfor Pembroke. I learnt how async/sync FSM semi-coupled/de-coupled\nproducts worked in the first supervision, and in the second I did more\nteaching than learning.</li>\n</ul>\n<h2>Self-hosting</h2>\n<p><span>I mentioned that I didn’t set up a\nPeerTube instance as my server doesn’t have enough storage, and Anil\nmentioned that he as some SSD’s lying around that we could repurpose\nwith a USB/SATA interface host hosting on the Pi in my\noffice.</span></p>\n<h2>Opam & Nix</h2>\n<p><span>I’ve implemented Spencer’s suggestion of\nsolving for a single instance of Nixpkgs for the Opam Nix backend for\nuse in the OCaml CI in a <a href=\"https://github.com/RyanGibb/opam-lang-repo-nix\">prototype</a>.</span></p>\n<p><span>I do so by creating a <code>nixpkgs</code>\npackage version for each Nixpkgs revision, that conflicts with other\nversions of itself. When we don’t care about this (when we’re not\nlinking the provided libraries together), such as providing a rust\ncompiler and python interpreter with versions from different instance of\nNixpkgs, I think this could be made optional with a custom variable\n& filter.</span></p>\n<p><span>The next step would be to generate this\nfrom the Nixpkgs repository itself. Currently I’m just using a few\nmanually cherry picked examples in a prototype: <a href=\"https://github.com/RyanGibb/opam-lang-repo-nix\">opam-lang-repo-nix</a>.</span></p>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}