Remove some old projects.
authorethereal <ethereal@ethv.net>
Sat, 25 Jan 2020 05:00:53 +0000 (00:00 -0500)
committerethereal <ethereal@ethv.net>
Sat, 25 Jan 2020 05:00:53 +0000 (00:00 -0500)
12 files changed:
src/projects/aesalon.md [deleted file]
src/projects/ethereality.md [deleted file]
src/projects/kriti.md [deleted file]
src/projects/metafrastis.md [deleted file]
src/projects/mjollnir.md [deleted file]
src/projects/static/ethereality-example-data.txt [deleted file]
src/projects/static/kriti-dist.tar.gz [deleted symlink]
src/projects/static/metafrastis.tar.gz [deleted file]
src/projects/static/mjollnir-spheres.png [deleted file]
src/projects/static/mjollnir.tar.gz [deleted file]
src/projects/sydi/design.md [deleted file]
src/projects/sydi/index.md [deleted file]

diff --git a/src/projects/aesalon.md b/src/projects/aesalon.md
deleted file mode 100644 (file)
index 876c396..0000000
+++ /dev/null
@@ -1,20 +0,0 @@
-%# Title: Aesalon
-
-Aesalon is an ongoing project to create a real-time program behaviour
-visualization tool. Originally started in 2009, it has undergone several
-rewrites and is currently on hiatus as of early 2012.
-
-The basic idea behind Aesalon is to collect data on how a program is
-interacting with its surrounding libraries and the operating system, and then
-construct interesting and useful displays and/or visualizations of the data.
-The system is designed to function both in real-time and using log files.
-
-The original scope of Aesalon was only to monitor the use of dynamically-
-allocated memory inside a target process; since then a rewrite has gifted it
-with a module system that allows for a much wider range of data collection.
-From I/O monitoring to thread-specific CPU use and semaphore/mutex locking/
-unlocking (deadlock-finding anyone?) through memory monitoring, Aesalon has the
-potential to be a very versatile tool.
-
-Unfortunately, it is currently not in a stable state, and hence there is no
-source snapshot available.
diff --git a/src/projects/ethereality.md b/src/projects/ethereality.md
deleted file mode 100644 (file)
index 84b6283..0000000
+++ /dev/null
@@ -1,126 +0,0 @@
-%# Title: ethereality
-
-ethereality is this website.
-
-### Static generation
-
-### Markdown
-
-### Syntax highlighting
-
-Integration with GNU `source-highlight` is available for use. If a Markdown
-verbatim block (indented with four spaces) begins with `language: html
-language: XYZ`, then the remainder of the block will be highlighted with
-`source-highlight` language specification `XYZ`. This makes it easy to produce
-nice code listings, such as:
-
-    language: C
-    #include <stdio.h>
-
-    int main(int argc, char *argv[]) {
-        printf("%s: Hello, World!\n", argv[0]);
-        return 0;
-    }
-
-It is also possible to use the same `language: html language: XYZ` syntax in
-inline (backquoted) Markdown code blocks, allowing things like `language: C
-sprintf(str, "Test %s\n", ...)` or `language: haskell 
-flip :: (a -> b -> c) -> b -> a -> c` or `language: lua function(a, b) return a
-.. ";" .. b end`.
-
-### LaTeX support
-
-There is full support for both inline and non-inline <$\text{\LaTeX}$>. Inline
-is done by putting content between a `<$` and `$>` pair; it defaults to
-math-mode, so to insert <$\text{\LaTeX}$> is `<$\text{\LaTeX}$>`. This makes
-writing inline math-mode <$\text{\LaTeX}$> very natural; for example, one might
-write
-
-    From here, we see that if <$x \geq 0$> then <$\sqrt{x}$> is defined, and
-    hence that <$x - \sqrt{x}$> is lower than <$x$>, making the algorithm
-    faster than the one originally proposed.
-
-To get:
-
-> From here, we see that if <$x \geq 0$> then <$\sqrt{x}$> is defined, and
-> hence that <$x - \sqrt{x}$> is lower than <$x$>, making the algorithm
-> faster than the one originally proposed.
-
-Non-inline <$\text{\LaTeX}$> is inserted by putting content between a pair of
-`<latex></latex>` tags in the Markdown input. The output is auto-centred.
-
-So, for example, to generate this:
-
-<latex>
-\begin{flalign*}
-    \sum_{k=0}^{10} {100 \choose k} + \sum_{k=90}^{100} {100 \choose k}
-        &= 2 \times \sum_{k=0}^{10} {100 \choose k} \\
-        &= 13215687346272
-\end{flalign*}
-</latex>
-
-One simply inserts
-
-    language: latex
-    <latex>
-    \begin{flalign*}
-        \sum_{k=0}^{10} {100 \choose k} + \sum_{k=90}^{100} {100 \choose k}
-            &= 2 \times \sum_{k=0}^{10} {100 \choose k} \\
-            &= 13215687346272
-    \end{flalign*}
-    </latex>
-
-### gnuplot integration
-
-By enclosing a list of gnuplot commands in `<plot></plot>` tags, it is possible
-to generate figures. For example, we can look at some relationships between 
-various functions of <$x$>:
-
-<plot>
-plot [-1:1] x + sqrt(x), x*x, x*x*x - x*x, x*x*x*x - x*x*x*x*x + x with lines;
-</plot>
-
-By putting this into the markdown:
-
-    language: HTML
-    <plot>
-    plot [-1:1] x + sqrt(x), x*x, x*x*x - x*x, x*x*x*x - x*x*x*x*x + x with lines;
-    </plot>
-
-Or, more interestingly, a plot of some accumulated data:
-
-<plot>
-    plot 'static/ethereality-example-data.txt' with lines;
-</plot>
-
-### graphviz integration
-
-By enclosing a graphviz description in `<graph></graph>` tags, it is possible
-to have graphs automatically rendered and inserted into the page. For example,
-we can insert a Petersen graph:
-
-<graph>
-graph petersen {
-    graph [dpi=72];
-    bgcolor=transparent;
-    layout=fdp;
-    scale=.5;
-    1 [pos="0.0, 0.0", pin=true];
-    2 [pos="2.0, -2.0", pin=true];
-    3 [pos="1.0, -4.0", pin=true];
-    4 [pos="-1.0, -4.0", pin=true];
-    5 [pos="-2.0, -2.0", pin=true];
-    6 [pos="0.0, -1.0", pin=true];
-    7 [pos="1.5, -2.0", pin=true];
-    8 [pos="1.0, -3.0", pin=true];
-    9 [pos="-1.0, -3.0", pin=true];
-    10 [pos="-1.5, -2.0", pin=true];
-    1 -- 2 -- 3 -- 4 -- 5 -- 1;
-    6 -- 8 -- 10 -- 7 -- 9 -- 6;
-    1 -- 6;
-    2 -- 7;
-    3 -- 8;
-    4 -- 9;
-    5 -- 10;
-}
-</graph>
diff --git a/src/projects/kriti.md b/src/projects/kriti.md
deleted file mode 100644 (file)
index 9de2b0f..0000000
+++ /dev/null
@@ -1,4 +0,0 @@
-%# Title: Kriti
-
-Kriti is (yet another) game engine using OpenGL for rendering. More information
-can be found on its [GitHub page](https://github.com/etherealvisage/kriti).
diff --git a/src/projects/metafrastis.md b/src/projects/metafrastis.md
deleted file mode 100644 (file)
index 5624f55..0000000
+++ /dev/null
@@ -1,16 +0,0 @@
-%# Title: Metafrastis
-
-Metafrastis was a course project to construct a compiler for a limited C-like
-language called J--
-([spec](http://cpsc.ucalgary.ca/~aycock/411/finalproject.html)). It generates
-ARMv15 assembly from the input, and the result can be executed in qemu's ARM
-semihosting mode.
-
-It uses flex/bison to construct an abstract syntax tree, and has an extremely
-stupid ad-hoc code generator present. I almost finished data-flow analysis but
-sadly ran out of time. As is, there's a few half-implemented optimizations
-floating around in the source tree; but I did finish some basic ones like
-constant folding and dead-code elimination.
-
-A source snapshot is [available](static/metafrastis.tar.gz), should you be
-curious.
diff --git a/src/projects/mjollnir.md b/src/projects/mjollnir.md
deleted file mode 100644 (file)
index 26f0d25..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-%# Title: Mjollnir
-
-Mjollnir (obvious Norse reference) is a distributed raytracer. By 'distributed'
-I don't mean in the graphics sense, but instead in the distributed systems
-sense. The idea is to split the renderable scene into chunks which can then
-be passed off to various worker threads running elsewhere.
-
-Mjollnir is not a very advanced raytracer (it doesn't always handle refraction
-properly, for example) but it does have fully-working distribution going for
-it. Raw network communication is done with BSD sockets, and serialization etc.
-is handled by boost::serialization. It uses my own custom Vector and
-Quaternion classes, as well as an R-tree for spatial partitioning. [^rtree]
-
-[^rtree]: There is a bug in this version of the R-tree such that scenes with
-more than a few dozen thousand objects will start to lose objects. It has been
-fixed elsewhere, but backporting the patch is a bit of a pain. If anyone wants 
-me to, I shall fix it. Until then, if you're looking for an R-tree
-implementation, use the R-tree source from Aesalon instead.
-
-With sufficient computers available for distribution, it produces some very
-nice images extremely quickly. It can, for example, render a scene with lots of
-reflective objects at a high anti-aliasing level:
-
-![Reflective spheres and planes](static/mjollnir-spheres.png)
-
-The full-sized 2730x1536 rendering takes approximately thirty seconds to render
-when distributed across three machines (i5-2400s at 3.1GHz), with four threads
-each.
-
-Downloads:
-
-* [Source snapshot](static/mjollnir.tar.gz)
diff --git a/src/projects/static/ethereality-example-data.txt b/src/projects/static/ethereality-example-data.txt
deleted file mode 100644 (file)
index 8d6830c..0000000
+++ /dev/null
@@ -1,100 +0,0 @@
-40.6
-52.3
-46.4
-41.8
-53.5
-49.6
-42.7
-46.8
-64.6
-56.8
-53.7
-41.6
-51.5
-54.9
-42.0
-44.2
-52.3
-64.6
-38.7
-48.5
-46.6
-57.1
-61.9
-47.1
-60.5
-45.8
-38.0
-53.0
-55.4
-49.2
-46.2
-55.6
-56.2
-39.2
-43.0
-44.0
-39.2
-38.7
-59.0
-47.0
-26.9
-50.3
-45.5
-46.7
-44.2
-48.2
-58.1
-43.8
-38.3
-27.2
-35.5
-51.9
-44.2
-50.1
-52.6
-57.3
-54.2
-65.0
-58.3
-63.3
-44.6
-26.7
-55.2
-51.8
-43.7
-57.2
-67.2
-42.9
-43.3
-52.1
-42.1
-42.4
-65.8
-46.5
-51.1
-54.3
-41.9
-37.3
-48.9
-42.9
-40.3
-33.3
-53.1
-49.7
-47.5
-69.5
-61.9
-47.9
-52.0
-53.2
-53.2
-50.4
-42.6
-65.7
-57.9
-48.2
-52.3
-42.3
-65.3
-49.0
diff --git a/src/projects/static/kriti-dist.tar.gz b/src/projects/static/kriti-dist.tar.gz
deleted file mode 120000 (symlink)
index 7537d8b..0000000
+++ /dev/null
@@ -1 +0,0 @@
-/home/kriti-ci/kriti-dist.tar.gz
\ No newline at end of file
diff --git a/src/projects/static/metafrastis.tar.gz b/src/projects/static/metafrastis.tar.gz
deleted file mode 100644 (file)
index dc79660..0000000
Binary files a/src/projects/static/metafrastis.tar.gz and /dev/null differ
diff --git a/src/projects/static/mjollnir-spheres.png b/src/projects/static/mjollnir-spheres.png
deleted file mode 100644 (file)
index cd41686..0000000
Binary files a/src/projects/static/mjollnir-spheres.png and /dev/null differ
diff --git a/src/projects/static/mjollnir.tar.gz b/src/projects/static/mjollnir.tar.gz
deleted file mode 100644 (file)
index d1b1943..0000000
Binary files a/src/projects/static/mjollnir.tar.gz and /dev/null differ
diff --git a/src/projects/sydi/design.md b/src/projects/sydi/design.md
deleted file mode 100644 (file)
index a353b36..0000000
+++ /dev/null
@@ -1,215 +0,0 @@
-%# Title: Sydi design
-
-Sydi follows the design philosophy of 'everything is a message-passing node'.
-There are two central parts to Sydi:
-
-* The message-passing API
-* The networking API
-
-Some terminology used:
-
-* A 'module' is a self-contained memory address space that can communicate with
-    other modules.
-* A 'channel' is a message-passing transport mechanism between modules.
-* A 'relay' is a module that does nothing other than pass message received from
-    one channel onto a second channel.
-* A 'node' is a computer running an instance of a Sydi-based operating system.
-* A 'cluster' is a group of nodes in contact with each other.
-
-### Message-passing in Sydi
-
-There are two types of message passing channels in Sydi: (each is implemented
-via a different protocol)
-
-* Queue
-* Broadcast
-
-A 'centralized' system (actually local to each node) manages the
-message-passing channels. If a module wants to communicate with another module,
-it requests that the local channel manager create a new channel -- which is
-assigned a globally-unique identifier; the second module then connects to said
-channel and can begin passing messages back and forth as necessary.
-
-This, of course, is not very feasible as it stands: there needs to be some
-common knowledge (i.e. the channel ID) before communication can begin. To that
-end, particular channels can be made non-anonymous by binding them to a name.
-Then, a module can ask to open a bound channel by name for reading/writing.
-
-#### General memory-based MP architecture
-
-Several contiguous pages are shared in memory between the various modules. Each
-channel has a designated region for a control header, and the rest is reserved
-for messages. No checks are placed upon what is read/written to/from the
-channel, and as a result, any of the connected modules are capable of putting
-the channel into an invalid state.
-
-To alleviate the difficulties of dealing with such things, a userspace API will
-be provided to manipulate the contents of the channels properly, and also to
-read with complete error-checking. Conforming programs will use the API to
-write, and hence not cause any problems; conforming programs will use the API
-to read as well, so if a non-conforming program tweaks the contents of a
-channel accidentally, the conforming programs (with the error-checking API)
-will not cause any undue failures.
-
-The API functions will return a special ERRNO-style value when the channel has
-been compromised.
-
-#### Queue
-
-The header contains the following elements:
-
-* Total channel size (including header),
-* Header size (in bytes),
-* Channel data alignment,
-* Data start position,
-* Data start mutex,
-* Data end position,
-* Data end mutex,
-* Current message count,
-* Current message count mutex.
-
-Each message has the following header:
-
-* Message size (excluding header),
-* Message state:
-    * `7` if message is being assembled,
-    * `3` if ready to be processed,
-    * `1` if processing is in progress,
-    * `0` if fully processed.
-
-To send a message, the following operations take place:
-
-* The data end mutex lock is acquired.
-* The data start position is read.
-* If the channel does not have enough space for the message + header: abort.
-* The data end position is modified to accomodate the new message + header.
-* The message header size is set appropriately, and the state is set to `7`.
-* The data end mutex lock is released.
-* The contents of the message are copied into the channel's memory.
-* The message header state is set to `3`.
-* The current message count is atomically incremented.
-
-To receive a message, the following operations take place:
-
-* The current message count mutex lock is acquired.
-* The current message count is read. If the count is zero, unlock and abort.
-* The current message count is decremented.
-* The current message count mutex lock is released.
-* The data start mutex lock is acquired.
-* Set the current message to be the message at the start of the data channel.
-* Loop:
-    * If current message has state `7`, abort the read process.
-    * Atomically bit test/clear current message state's second bit. 
-    * If bit was clear, skip this message and move onto the next in the
-        channel.
-    * Select this message and exit the loop.
-* The data start mutex lock is released.
-* Copy message contents out of the channel and into local memory.
-* The data start mutex lock is acquired.
-* Set the current message to be the message at the start of the data channel.
-* Loop:
-    * Atomically bit test/clear current message state's first bit. 
-    * If bit was set, skip this message and move onto the next in the channel.
-    * Set the data start position to the end of the current message and exit
-        the loop.
-* Return the copied message.
-
-#### Broadcast
-
-The channel header contains the following elements:
-
-* Total channel size (including header),
-* Header size (in bytes),
-* Channel data alignment,
-* Data start position,
-* Data start mutex,
-* Data end position,
-* Data end mutex,
-* Current message count,
-* Current message count mutex,
-* Number of qwords to use for 'processed' bitset in each message header,
-* Maximal 'processed' bitset.
-
-Each message has the following header:
-
-* Message size (excluding header),
-* Message state:
-    * `7` if message is being assembled,
-    * `3` if ready to be processed,
-    * `1` if processing is in progress,
-    * `0` if fully processed.
-* Number of qwords in 'processed' bitset,
-* The 'processed' bitset qwords.
-
-#### General network-based MP architecture
-
-There are, as before, two separate 
-
-### Distributed topography
-
-The fact that Sydi operates in a distributed fashion is one of the trickier
-things to deal with. When a new Sydi node is started, it needs the IP addresses
-of already-started node(s). If none respond to requests, then it begins a new
-Sydi cluster. There are no plans to allow clusters to merge.
-
-Nodes within a Sydi cluster follow a traditional distributed network model:
-each node is connected to a number of other nodes, but perhaps not all. Nodes
-are required to forward communications between their neighbours if their
-neighbours do not 'know about' each other, i.e. have no direct connection.
-
-There are some operations that require a global lock to be held, such as:
-
-* Adding a new node to the cluster
-* Recalculating reachability status
-
-These are accomplished via a broadcast mechanism typical of distributed
-systems.
-
-### Control messages
-
-Nodes in a cluster maintain TCP connections with each other to send control
-messages to each other. A short list of such message types:
-
-#### Request types
-
-* Request new node ID: nothing in request, result is both a new node ID and a
-    list of existing node IDs. This request involves the global lock.
-
-* Request routing list: nothing in request, returns a list of node IDs that
-    the receiving node can communicate with.
-
-* Request load factors: nothing in request, returns a list of 'load factors'
-    for each node ID.
-
-#### Notification types
-
-* Notify dropped node: notification includes node ID that has been dropped.
-
-* Notify channel closed: notification that a communication channel
-    reader/writer has been closed.
-
-### Module migration
-
-If a node is deemed overloaded, and a module is estimated to be 'good' to move,
-then the contents of the address space of the module are transferred to another
-node, and network relays are added to allow the channels to continue
-uninterrupted.
-
-The weighting formula includes:
-
-* Amount of single-reader channel reads/writes performed
-* Amount of multi-reader channel reads performed
-* Amount of multi-writer channel writes performed
-* Address space size
-* Whether the module is a relay
-
-Eventually the address space information will be compressed using gzip or
-something similar to save bandwidth, but not immediately (for simplicity).
-
-### Node-to-node communication encryption
-
-Certain tasks, such as module migration, may involve sensitive information
-being transmitted between nodes. To that end, Sydi will provide the option to
-have all node-to-node communication encrypted via a simple Diffie-Hellman
-handshake/AES running in CBC. Such a model is vulnerable to man-in-the-middle
-attacks, but will defeat passive monitoring.
diff --git a/src/projects/sydi/index.md b/src/projects/sydi/index.md
deleted file mode 100644 (file)
index 73789ea..0000000
+++ /dev/null
@@ -1,10 +0,0 @@
-%# Title: Sydi
-
-Sydi is a project to create a distributed microkernel-based operating system,
-with transparent process migration between networked running instances of the
-kernel. It targets x86_64 platforms, and is currently in a very early stage of
-development.
-
-For some design philosophy for Sydi, see the [design](design) page.
-
-There are currently no downloads available for Sydi.