ripple/website: init

This contains the source to Ripple's website, as it was published on 2020-10-07. Change-Id: I4c871be79d8841b277d23ea741c8728ec5da8cc8
author: V <v@unfathomable.blue> 2021-02-25 21:17:45 +0100
committer: V <v@unfathomable.blue> 2021-02-25 21:55:23 +0100
commit: f5c8a8537a336b60fd28af003572fa8883fc8354 (patch)
tree: 7374f969bae7709fa78388a0dc288f926ade1f3b
parent: 2f487c3bf7cd8efd64f1d217edac732db98ff1c0 (diff)
download: unf-legacy-f5c8a8537a336b60fd28af003572fa8883fc8354.tar.zst
4 files changed, 120 insertions, 0 deletions
diff --git a/ripple/website/README.md b/ripple/website/README.md
new file mode 100644
index 0000000..1eaafb0
--- /dev/null
+++ b/ripple/website/README.md
@@ -0,0 +1,5 @@
+# Source code for https://ripple.unfathomable.blue/
+
+To test your changes, build the website using `nix-build`, and run
+`nix-shell serve.nix` to serve `./result` at `http://localhost:8080/`.
+The live website is built directly from `HEAD`.
diff --git a/ripple/website/default.nix b/ripple/website/default.nix
new file mode 100644
index 0000000..f72e5af
--- /dev/null
+++ b/ripple/website/default.nix
@@ -0,0 +1,16 @@
+let pkgs = import <nixpkgs> {};
+in pkgs.runCommand "ripple.unfathomable.blue" {
+  nativeBuildInputs = [ pkgs.lowdown ];
+} ''
+  mkdir $out
+  for x in ${./pages}/*.md; do
+    {
+      cat <<EOS
+  <!DOCTYPE html>
+  <title>$(lowdown -X title $x)</title>
+  <style>body { max-width: 72ch; margin: auto; }</style>
+  EOS
+      lowdown --html-no-head-ids $x
+    } >$out/$(basename $x .md).html
+  done
+''
diff --git a/ripple/website/pages/index.md b/ripple/website/pages/index.md
new file mode 100644
index 0000000..3fac3ac
--- /dev/null
+++ b/ripple/website/pages/index.md
@@ -0,0 +1,74 @@
+title: Ripple
+
+# A build system for the next decade
+
+Ripple is an experimental build system. Blending functional reactive
+programming, process tracing, automatic memoization, and a smattering of
+object capabilities, it aims to completely redefine the state of the art
+in software assembly.
+
+Ripple will provide completely [reproducible builds](https://reproducible-builds.org/), guaranteeing that
+any piece of software which builds successfully on one computer can be
+recreated bit-for-bit identically on any other computer — even ten years
+down the line. This allows users of binary packages to be confident that
+they're running software directly corresponding to published source
+code.
+
+While reproducible builds are nothing new, combining them with automatic
+fine-grained incremental compilation is necessary to make them usable
+every step of the way, as opposed to something only performed at
+software release time. By doing so, Ripple will banish invocations of
+`make clean` to antiquity, and save billions of hours of CPU time wasted
+by CI systems pointlessly rebuilding the same thing over and over again.
+
+In addition, Ripple will take care of some other tricky problems, like
+coherently expressing precisely versioned dependencies across language
+ecosystem boundaries, correct cross-compilation support, and precise
+runtime/build-time dependency calculation.
+
+## Doesn't this exist already?
+
+No. I've looked.
+
+## Why doesn't this exist already?
+
+While I can't answer this for sure, I would posit the following: build
+systems and package managers are [infrastructure](https://www.destroyallsoftware.com/talks/a-whole-new-world).
+They cannot be marketed (who would pay for a build system in this day
+and age?) and need to be rethought from the ground up, so the design and
+implementation of such is relegated to a select few: academics, bored
+nerds, and very large companies with insane scaling requirements.
+
+Academic research projects are usually left to gather dust once the
+thesis is said and done. Nerds build toy clones of existing software,
+except it's going to be better this time. Megacorps don't need their
+build system to handle reproducibility — they just vendor everything
+into their humongous monorepo and call it a day.
+
+## Why don't you just ...?
+
+Given that existing package managers and build systems overlap in scope
+with Ripple, this is a perfectly reasonable question to ask. Why not
+just combine [two](https://github.com/NixOS/nix) [existing](https://bazel.build/) tools which each hold half of the solution?
+
+On a surface level, this seems perfectly innocent: reducing the amount
+of work that has to be put in and avoiding fracturing ecosystems is
+surely a good thing! Digging deeper, however, you'll quickly realise
+the following: in order for each side to function efficiently in this
+arrangement, they need some fairly invasive modifications to integrate
+with each other. Hard fork territory.
+
+So, attempting to reuse existing software would require some fairly
+significant effort nonetheless, and also involve taking on legacy from
+the get-go. On the other hand, designing a new system from the ground
+up will be vastly simpler, as we can entirely do away with the build
+system/package manager dichotomy and make entire swaths of cross-cutting
+concerns disappear into thin air.
+
+## Why doesn't *this* exist already?
+
+Designing and implementing a project of this scope and complexity is
+going to require a significant investment of time and energy. It's not
+something that will get to a usable state in the near future if I'm just
+tinkering on it at the weekend, so I'm currently seeking funding that
+would allow me to work on it full-time. Watch this space!
diff --git a/ripple/website/serve.nix b/ripple/website/serve.nix
new file mode 100644
index 0000000..476b0b7
--- /dev/null
+++ b/ripple/website/serve.nix
@@ -0,0 +1,25 @@
+let
+  pkgs = import <nixpkgs> {};
+  config = builtins.toFile "Caddyfile" ''
+    {
+      admin off
+    }
+
+    :8080
+
+    try_files {path}.html {path}
+    file_server {
+      root result
+    }
+
+    handle_errors {
+      respond "{http.error.status_code} {http.error.status_text}"
+    }
+
+    log {
+      format single_field common_log
+    }
+  '';
+in pkgs.mkShell {
+  shellHook = "exec ${pkgs.caddy}/bin/caddy run --adapter caddyfile --config ${config}";
+}
author	V <v@unfathomable.blue>	2021-02-25 21:17:45 +0100
committer	V <v@unfathomable.blue>	2021-02-25 21:55:23 +0100
commit	f5c8a8537a336b60fd28af003572fa8883fc8354 (patch)
tree	7374f969bae7709fa78388a0dc288f926ade1f3b
parent	2f487c3bf7cd8efd64f1d217edac732db98ff1c0 (diff)
download	unf-legacy-f5c8a8537a336b60fd28af003572fa8883fc8354.tar.zst