hey, glad you could make it! this is a basic guide (with gifs) on how to install urbit and boot a comet. this guide howeever will also be going into some of my own qol tricks, but youll see a bit later.
okay so lets get started!
oh and also sorry about the extremely low quality of all my gifs. its 2 am and ive never done this kind of thing before, so bare with me
Add yourself to the docker group to be able to run containers as non-root (see Post-install steps for Linux).
| htpasswd -bc docker-registry.htpasswd admin admin | |
| scp docker-registry.htpasswd admin@${NAS_IP}:/share/CACHEDEV1_DATA/Container/container-station-data/application/registry/nginx/ |
I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.
There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.
As an example, currently we can express this type:
F(x) that would make it return yx
Imagine a situation where Alice has an account with $100 in it. This is a special kind of account that allows her to give out special spending limit codes to her friends which allow them to in turn to give out their own spending-limit codes.
For example, imagine this set of signed messages:
This is not an exhaustive list of all interfaces in Go's standard library.
I only list those I think are important.
Interfaces defined in frequently used packages (like io, fmt) are included.
Interfaces that have significant importance are also included.
All of the following information is based on go version go1.8.3 darwin/amd64.
Example read model projections using Commanded Ecto projections where Elixir's Registry is used for pub/sub notifications of read model updates.
This alleviates the problem of async read model updates.
The command dispatcher can wait until the read model has been updated to the exact aggregate version (as returned by the dispatch command):
with {:ok, version} <- Router.dispatch(register_user, include_aggregate_version: true) do
Ubuntu, Fedora, openSUSE, CentOS, SUSE Linux Enterprise, Debian,... users can finally use Autodesk Fusion 360 in the Linux Browser now.
On Chromium 55.0.2843.0 I get NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.
IPLD-based Version History
This is just a sketch of a possibility. If we just want a git-style toolchain with git version graph, it might be better to just put an ipfs storage adapter behind go-git -- basically putting IPFS unixfs trees where git usually creates git tree objects. In that case you would have regular git commit objects, not IPLD objects. That would be less reusable beyond the git context but it would fit better with existing git-based tooling.
Keep in mind: it will be really useful to be able to use IPFS files api to manipulate these trees, allowing you to do things like modify part of a large dataset and commit the changes without ever pulling the whole dataset -- you can just pull the parts that you're changing.