harvey-os / harvey Goto Github PK

Alvaro has pointed out that there are .h files that we can remove, now that ape is a separate repo. We need the list.

Please, see in our Google group last state of this issue.

Download page maybe should be called 'getting started' but should not refer to gerrithub.io

I can't cpu to Harvey because devcap and devssl are missing.

Expected behavior

Gerrit doesn't suck.

Actual behavior

Gerrit sucks.

Steps to reproduce

Use Gerrit.

We should:

• remove specialized implementations for platforms we do not maintain
• introduce const modifiers where appropriate in function signatures
• replace int arguments with uint8_t in memccpy, memchr and memset (and check if we have any performance loss)
• fix gmtime and localtime to get a Tm *tm to fill instead of returning static data whose content is overwritten by each call (return value should then be void)
• fix getcallerpc signature: the firstarg parameter is not necessary.
• fix abort to produce useful messages

We need a minimal set of simple and powerful syscalls that can be considered stable.

Thus we have to replace syscalls that can be expressed in term of the others (eg sleep and alarm can be moved to user space using awake) and decide what to do with those syscalls that we inherited but are not currently available in any C header (maybe some are going to be removed and others to be improved).

One of my CLs went off the rails a bit and did this before getting reigned in, but it'll turn out better if discussed: how should util/build work if the BUILD script in the root is removed? (The implicit assumption here is that it'd be nice if it was removed.)

BUILD does some sequencing of util/build invocations, so that would have to be encoded in the json buildfiles somehow.

Should it understand barewords, like all or utils or libs? Should it have a default filename?

I think cramming too much more functionality into it gets away from a simple tool that can be told how to invoke the toolchain.

The standard way in to Plan 9 is drawterm. We're close.

build.json includes /util/nvram to ease integration of factotum during development.

However, we don't want every Harvey node in the world to have the same hostowner and password.

This is a reminder until Harvey could be distributed with an install program which sets up nvram.

The general process will be:

Grab and verify the tarball as normal, then for every file that would get written out to disk, instead checksum against the preexisting file on disk.

This should require one boolean flag (-check).

Given we want to replace libsec, we need a modern well established crypto library that will replace it.
Since it's required by the kernel (random number generation, devtls and so on), it's going to be part of our core system.

Thus we need

1. to native port it, with the long term goal of contributing the port to the upstream community
   • to native port its dependencies, with the long term goal of contributing the port the respective upstream communities
   • to keep control on the version we use, avoiding to automatically include the "latest" version
2. to minimize our impact on code that we do not really understand
3. to be able to add our own regression tests
4. to be able to run all tests provided by the upstream libraries that apply to Harvey

To minimize the risk of introducing bugs in the code we get, we adopt a convention based, automated process:

1. create a folder in source for each third party source we import
   1. create a .gitignore containing upstream/, port/* and any further temporary item required
   2. create a port/ folder that will contains the sources actually compiled.
   3. write the uri of the sources to download to port/UPSTREAM
2. create a common.json that define Pre commands to
   1. verify the downloaded tar sha256sum against a known valid checksum
   2. untar the sources in a newly created upstream/ folder (if not already present)
3. create a build.json in that folder that
   1. fetches a specific version of the sources
   2. includes one or more specific json Projects that will do the actual port
   3. on Post write the url of the downloaded sources in port/UPSTREAM
   4. fail if git reports that port/UPSTREAM has changed

Then in each custom project we can do the automatic port (carefully using tools and semantics available on Harvey user space).
Any header added to /sys/include during the process must be added to $HARVEY/.gitignore and conforms to the Harvey conventions (that is, it should not contains macro guards or #ifdef unrelated to Harvey)

This way we

• keep control on the version included (with checksum and uri verifications that will be attributed to the proper author in the repo history)
• minimize bandwidth: upstream sources are downloaded only once in compressed form
• minimize repo size: external sources are gitignored (consider we are talking about libraries that can be as large and complex as our whole OS)
• can add as many regression test as we need
• are ready to contribute back to upstream
• can easily (but visibly) update the version imported
• can easily remove our hacks when upstream community will start to support Harvey

NOTE
This process is specifically designed for cryptographic tools that are going to be part of the core native system. It does not impose or propose any rule or constraint on other kind of native or glibc based port.

2016/02/19 16:20:34 /usr/bin/ld -o nfs nfs.o -static -e_main -lavl -lcomplete -lcontrol -ldisk -lflate -lframe -lgeometry -lhttpd -lbin -llex -lmemdraw -lmemlayer -lmemdraw -ldraw -lplumb -lregexp -lstdio -lString -lsunrpc -loventi -l9p -lauth -lauthsrv -lndb -lip -lventi -lsec -lauth -lmp -lthread -lmach -lbio -lc -L /home/ubuntu64/harvey/amd64/lib
nfs.o：在函数‘mountMnt’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:130：对‘nfs3Errstr’未定义的引用
nfs.o：在函数‘nfsGetattr’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:191：对‘nfs3Errstr’未定义的引用
nfs.o：在函数‘nfsAccess’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:217：对‘nfs3Errstr’未定义的引用
nfs.o：在函数‘nfsMkdir’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:252：对‘nfs3Errstr’未定义的引用
nfs.o：在函数‘nfsCreate’中：
/home/ubutu64/harvey/sys/src/cmd/nfs.c:291：对‘nfs3Errstr’未定义的引用
nfs.o:/home/ubuntu64/harvey/sys/src/cmd/nfs.c:327: more undefined references to `nfs3Errstr' follow
nfs.o：在函数‘nfsReadDirPlus’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:544：对‘nfs3EntryPlusUnpack’未定义的引用
nfs.o：在函数‘nfsReadDir’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:590：对‘nfs3Errstr’未定义的引用
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:597：对‘nfs3EntryUnpack’未定义的引用
nfs.o：在函数‘threadmain’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:1576：对‘nfs3Prog’未定义的引用
nfs.o：在函数‘dialproc’中：
/home/ubuntu64/harvey/sys/src/cmd/nfs.c:1643：对‘nfs3Prog’未定义的引用
2016/02/19 16:20:34 exit status 1

These two scripts need awk and we've worked around it by commenting awk out.

Let's get an awk we can use.

refers to envsetup, which is gone.

The current implementation of sqrt.s segfaults.

Since we have a C portable version that works, we temporary remove sqrt.s, to avoid duplicated definitions.

In the long term however, we have to fix sqrt.s since amd64 provides a dedicated instruction.

Lock(2) functions do not handle timeouts. We need them.

We can easily implement a lockt function based on tsemacquire, but for QLock, RWLock and Rendez we need a way to interrupt rendezvous(2).

Alarms might work, but being based on notes, they are not efficient enough.

We should always be able to build with -Werror

We need to get Go test working, as they are an excellent stressor for the OS

When aborting 9p requests we seem to lose track of fids, such that the server thinks they are in use and the kernel does not.

Can't find #P/realmodemem

Expected behavior

stats does not fail when stats window clicked on with right mouse button

Actual behavior

stats quits and displays something like the following in the rio window
stats 90: suicide: sys: trap: fault write addr=0x41fd60 pc=0x4169fc

Steps to reproduce

Approach 1:

• Start harvey / rio, create 2 windows:
• Create window #1
• Run 'stats' in window #1
• Create window #2
• After creating window #2, right mouse button click on the stats window #1
• Error is displayed
  Can continue to recreate the error: Create new stats windows (#3 etc). Put focus on another window and then right click on stats window (#3 etc.). Same error is generated again.

Approach 2

• Start harvey / rio, create 1 windows:
• Run 'stats' in window #1
• Left mouse button click on the rio background
• Right mouse button click on stats window (#1)

QEMU output

init: starting /bin/rc
10.0.2.15 Feb 26 18:44:16 starting dns resolver on 10.0.2.15's /net
machp access spllo, stack: k:13f4cf k:138864 k:19cb35 k:11a7d3 k:1de3d7 k:1de621 k:148db8 k:139695
vbecall: sizeof u is 76
vbecall: sizeof u is 76
vbecall: sizeof u is 76
machp access spllo, stack: k:13f4cf k:138864 k:142638 k:1221f5 k:163892 k:121402 k:11b09c k:11b3be k:1de7b3 k:1de9f4 k:148db8 k:139695
machp access spllo, stack: k:13f4cf k:138864 k:19cabf k:19c82b k:121380 k:11ae09 k:11b3be k:1de7b3 k:1de9f4 k:148db8 k:139695
machp access spllo, stack: k:13f4cf k:138864 k:19caea k:1a4b00 k:1a464f k:1de7b3 k:1de9f4 k:148db8 k:139695
machp access spllo, stack: k:13f4cf k:138864 k:1a48c5 k:1de7b3 k:1de9f4 k:148db8 k:139695
machp access spllo, stack: k:13f4cf k:138864 k:1a4a61 k:1a49dc k:1de7b3 k:1de9f4 k:148db8 k:139695
machp access spllo, stack: k:13f4cf k:138864 k:13d69f k:194f81 k:193dc7 k:1de3d7 k:1de621 k:148db8 k:139695
write fault fail Load(r-x) pid 90 addr 0x41fd60 pc 0x4169fc

we have too many clickthroughs for my test. The 'how to get prereqs' is a clickthrough to like 12 lines of text Why the indirection?

Expected behavior

Running mahjongg in a rio window should result in the mahjongg game being displayed.

Actual behavior

rio freezes and the following error message is displayed, both over the rio screen and in the QEMU window:
read fault fail, no segment, pid 82 addr 0x0 pc 0xfffffffff0150365
qlock with ilockdepth 1, stack: k:1df7a3 k:1da556 k:155220 k:1545de k:154382 k:138f90 k:20a39d k:20a1fb k:20afeb k:20b999 k:1f5755 k:14114b k:140ac5 k:1e76b2 k:1e78f3 k:152b4d k:139695
panic: cpu0: cpu0: ilockdepth 1, last lock 0x0 at 0x0, sched called from 0xfffffffff014a1b5

Steps to reproduce

• Start harvey and rio
• Open a window
• At the command prompt enter: mahjongg
• Above error message is displayed

QEMU output

As above

It's not handling fork well for some reason.This could be a word size issue again.

If you cat /bin/rc it seems like the console server always returns EOF on read from that point on. Or it's dying? I'm not sure.

Could we drop it in favor of libssl?
Could be a wrapper to libssl?
Do we really need devssl/tls in kernel?

That function was meant to be called with the queue locked. #mnt doesn't
lock it - nor does it or any other file have a mechanism to do so. So it's
always a bad idea to call qremove. It looks like #mnt wants qget().

Signed-off-by: Barret Rhoden [email protected]

Not sure if this is a problem in Plan 9 / Harvey or not.

kern/drivers/dev/mnt.c | 2 +-
kern/include/ns.h | 1 -
kern/src/ns/qio.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/kern/drivers/dev/mnt.c b/kern/drivers/dev/mnt.c
index b9036cc438bb..df3dd304b319 100644
--- a/kern/drivers/dev/mnt.c
+++ b/kern/drivers/dev/mnt.c
@@ -969,7 +969,7 @@ int mntrpcread(struct mnt *m, struct mntrpc *r)
l = &r->b;
*l = NULL;
do {

•           b = qremove(m->q);
  

•           b = qget(m->q);
          /\* TODO: have better block helpers for this and the memmove below _/
          b = linearizeblock(b);
          if (hlen > 0) {
  

  diff --git a/kern/include/ns.h b/kern/include/ns.h
  index 53d77b5a0f83..32e3052695eb 100644
  --- a/kern/include/ns.h
  +++ b/kern/include/ns.h
  @@ -836,7 +836,6 @@ ssize_t qpass(struct queue *, struct block *);
  ssize_t qpassnolim(struct queue *, struct block *);
  void qputback(struct queue *, struct block *);
  long qread(struct queue *, void *, int);
  -struct block *qremove(struct queue *);
  void qreopen(struct queue *);
  void qsetlimit(struct queue *, int);
  int qwindow(struct queue *);
  diff --git a/kern/src/ns/qio.c b/kern/src/ns/qio.c
  index d6ddd278c96e..066a4f3e379e 100644
  --- a/kern/src/ns/qio.c
  +++ b/kern/src/ns/qio.c
  @@ -1177,7 +1177,7 @@ void qaddlist(struct queue *q, struct block *b)
  /_
  • called with q ilocked
    */
    -struct block *qremove(struct queue *q)
    +static struct block *qremove(struct queue *q)
    {
    struct block *b;

2.8.0.rc3.226.g39d4020

This issue is open to note here all the things we are finding about problems running Harvey in Qemu, hacks made for this or broken things.

Delay in boot:
https://review.gerrithub.io/#/c/259279/

main.c:178
"// FIX QEMU. extern int64_t hz;
int64_t hz;"

9p is a dog. It has some fundamental design limits which seem to cause performance problems. One of them is the requirement that all operations on a connection be serialized. Another is that it's always one connection.The statefulness of 9p, which at one point seemed sensible, is now an anchor dragging along behind it.

We need to investigate newer protocols to see if they are better. Now that we can select from multiple mount devices, we could mount those new protocols over a new mount device and see if performance improves.

We can also investigate improvements to 9p but, note, the problem is much, much harder than it first seems.

travis-ci by default provides GCC 4.6 that does not support -Wmaybe-uninitialized. However, we always use such flags with -Wall, so that it becomes redundant in gcc versions that support it.

So we should

• remove -Wmaybe-uninitialized whenever used with -Wall
• force travis to use a modern gcc.

Before the section "push the changes to your new remote" there needs to be a section "git remote set-url USER_NAME https://github.com/grd/harvey.git"

Harvey hasn't any cons available before calling factotum for authentication.

The ramdisk in plan 9, which runs in user mode, is a dog. It has a major impact on the performance of go test. We need a kernel ramdisk.

Hi,

I tried to push to gerrit, not a particularly complicated change, I just fixed some warnings, but it keeps getting rejected with:

! [remote rejected] HEAD -> refs/for/master (not Signed-off-by author/committer/uploader in commit message footer)

What am I missing?

Keith

Given we want to replace libsec, we need a modern well established crypto library that will replace it.
Since it's required by the kernel (random number generation, devtls and so on), it's going to be part of our core system.

Thus we need

1. to native port it, with the long term goal of contributing the port to the upstream community
   • to native port its dependencies, with the long term goal of contributing the port the respective upstream communities
   • to keep control on the version we use, avoiding to automatically include the "latest" version
2. to minimize our impact on code that we do not really understand
3. to be able to add our own regression tests
4. to be able to run all tests provided by the upstream libraries that apply to Harvey

All this should be achieved

1. preserving reproducible builds and our ability to use git bisect
2. adopting a trust-less semi automatic and verifiable process during the updates of the library, to prevent
   • the introduction of security flaws in the imported sources (that could pass unnoticed during a large update to a new upstream version)
   • any delay of critical security updates that could advantage an attacker
   • the introduction of security flaws in the port scripts (that could pass unnoticed during a large update to a new upstream version)

To this aim we decided to code a set of Go utilities that can automatically vendor a source archive according to directives described in a json file (from download to checksum, including a final git commit with a standardized message) and automatically verify that the code imported matches the one contained in the archive declared in the json,
This tool would prevent the first obvious threat described above and will reduce the risk of the second, as it is pointless to discuss an automated commit that builds, passes the regression tests and pass the source verification: the only check that remains to reviewers (on this regard) is to ensure that the URI of the archive prescribed in the json and its digests actually match the intended one.

To address the third possible threat in an (almost) trust-less fashion, we need to be able to easily review the port scripts when the are updated. This unfortunately precludes the use of patch files because they are sensible to many small non-semantic changes that can occur during a version update and that, all together, can hide to a human reviewer a single semantic change (think for example to the removal of a single null check hidden in a large patch-set addressing whitespace changes, #include replacements and so on).

For this reason we are going to use dedicated easy to read scripts for every single transformations that the sources will require: for example during a review it is much easier to ensure that a remove-stdio-include.sed script behaves correctly, than the same transformation spread in dozen of patch files (or in one patch targeting multiple files).

In the long term, when Harvey will be a mainstream OS supported like any other by the upstream developers, the vendor tool and its automatic checker will be still useful for updates: we will only need to remove the porting scripts from the build,json.

Expected behavior

/path/to/fs.c: In function ‘keylist’:
/path/to/fs.c:471:14: warning: unused variable ‘zero’ [-Wunused-variable]
static char zero[Nearend];

Actual behavior

fs.c: In function ‘keylist’:
fs.c:471:14: warning: unused variable ‘zero’ [-Wunused-variable]
static char zero[Nearend];

This is quite annoying when there are multiple fs.c files that you have to locate and try out. I discovered that GCC uses the path that is given as input, see https://stackoverflow.com/questions/1282392/can-gcc-be-configured-to-not-print-out-a-full-path-in-warning-error-messages

The solution would be to resolve the complete path of the compiled source file in the build program.

Expected behavior

Compilation without errors.

Actual behavior

Compilation errors with:
2016/03/23 21:01:08 "mksys -o sys.h '-mode=sys.h' $HARVEY/sys/src/sysconf.json " | /bin/sh
/bin/sh: 1: mksys: not found

I think that setting the HARVEY environment variable is the problem. (On Linux)

We should organize libmach so that we can ignore unsupported architectures using $ARCH.

Once no #ifdef appear in the code, we should remove unsupported architectures (one per CL) referencing this issue, so that we can simply revert the commit when someone will want to restore them.

Due to a varargs issue, run/runv functions can't work as usual.
Among other things, we must use shell (rc) to prepare disk for botting the system, doing various part of the work that were done by bootloader in Plan 9.

refer to this bug when you push devmnt performance changes.

With a root file system imported over 9p

bind -a '#K' /dev
echo -n opstart > /dev/kprofctl
cat /bin/* > /dev/null

takes a page fault in the kernel

• sys/src/9/386/386
• sys/src/9/amd64/amd64coreboot
• sys/src/9/amd64/amd64cpu
• sys/src/9/amd64/clean
• sys/src/9/amd64/core
• sys/src/9/amd64/inith
• sys/src/9/boot/boot
• sys/src/9/boot/bootconf
• sys/src/9/ip/ip
• sys/src/9/port/port
• sys/src/bench/build
• sys/src/cmd/9660srv/9660srv
• sys/src/cmd/9nfs/9nfs
• sys/src/cmd/9nfs/pcnfsd
• sys/src/cmd/9nfs/portmapper
• sys/src/cmd/acme
• sys/src/cmd/astro/astro
• sys/src/cmd/auth/auth
• sys/src/cmd/auth/authsrv
• sys/src/cmd/auth/dsa2pub
• sys/src/cmd/auth/dsa2ssh
• sys/src/cmd/auth/factotum/factotum
• sys/src/cmd/auth/guard.srv
• sys/src/cmd/auth/lib/libauthcmd
• sys/src/cmd/auth/rsa2csr
• sys/src/cmd/auth/rsa2pub
• sys/src/cmd/auth/rsa2ssh
• sys/src/cmd/auth/rsa2x509
• sys/src/cmd/auth/rsafill
• sys/src/cmd/auth/secstore/aescbc
• sys/src/cmd/auth/secstore/secstore
• sys/src/cmd/auth/secstore/secstored
• sys/src/cmd/auth/secstore/secuser
• sys/src/cmd/aux/aux
• sys/src/cmd/aux/console/comconsole
• sys/src/cmd/aux/console/pipeconsole
• sys/src/cmd/aux/console/screenconsole
• sys/src/cmd/aux/flashfs/dummyfs
• sys/src/cmd/aux/flashfs/flashfs
• sys/src/cmd/aux/flashfs/flashfsbin
• sys/src/cmd/aux/flashfs/mkflashfs
• sys/src/cmd/aux/flashfs/testldfs
• sys/src/cmd/aux/gps/gps
• sys/src/cmd/aux/gps/gpsevermore
• sys/src/cmd/aux/mnihongo/mnihongo
• sys/src/cmd/aux/realemu/loadcom
• sys/src/cmd/aux/realemu/realemu
• sys/src/cmd/aux/vga/vga
• sys/src/cmd/bzip2/bzip2
• sys/src/cmd/bzip2/lib/libbzip2
• sys/src/cmd/cb/cb
• sys/src/cmd/cdfs/cdfs
• sys/src/cmd/cifs/cifs
• sys/src/cmd/cmd
• sys/src/cmd/cmds
• sys/src/cmd/con/con
• sys/src/cmd/dial/dial
• sys/src/cmd/diff/diff
• sys/src/cmd/disk/9660/9660
• sys/src/cmd/disk/disk
• sys/src/cmd/disk/kfs/kfs
• sys/src/cmd/disk/prep/fdisk
• sys/src/cmd/disk/prep/prep
• sys/src/cmd/dossrv/dossrv
• sys/src/cmd/exportfs/exportfs
• sys/src/cmd/fossil/flchk
• sys/src/cmd/fossil/flfmt
• sys/src/cmd/fossil/fossil
• sys/src/cmd/fossil/last
• sys/src/cmd/grep/grep
• sys/src/cmd/hoc/hoc
• sys/src/cmd/iostats/build
• sys/src/cmd/ip/dhcpd/dhcpd
• sys/src/cmd/ip/dhcpd/dhcpleases
• sys/src/cmd/ip/ftpd
• sys/src/cmd/ip/ftpfs/ftpfs
• sys/src/cmd/ip/httpd/httpd
• sys/src/cmd/ip/httpd/libhttps
• sys/src/cmd/ip/imap4d/imap4d
• sys/src/cmd/ip/ip
• sys/src/cmd/ip/ipconfig/ipconfig
• sys/src/cmd/ip/ipconfig/kipconfig
• sys/src/cmd/ip/ppp/ppp
• sys/src/cmd/kcmds
• sys/src/cmd/kernel
• sys/src/cmd/ndb/dns
• sys/src/cmd/ndb/dnsdebug
• sys/src/cmd/ndb/dnstcp
• sys/src/cmd/ndb/ndb
• sys/src/cmd/rc/rc
• sys/src/cmd/rio/rio
• sys/src/cmd/syscall/syscall
• sys/src/cmd/usb/build
• sys/src/cmd/usb/usbd/build
• sys/src/cmd/usb/usbd/usbdb
• sys/src/cmd/usb2/keyb
• sys/src/cmd/usb2/usb
• sys/src/cmd/venti/srv/libvs
• sys/src/cmd/venti/srv/srv
• sys/src/cmd/venti/venti
• sys/src/klib
• sys/src/klibs
• sys/src/lib
• sys/src/lib9p/lib9p
• sys/src/libauth/libauth
• sys/src/libauthsrv/libauthsrv
• sys/src/libavl/libavl
• sys/src/libbin/libbin
• sys/src/libbio/libbio
• sys/src/libc/9syscall/9syscall
• sys/src/libc/klibc
• sys/src/libc/libc
• sys/src/libcomplete/libcomplete
• sys/src/libcontrol/libcontrol
• sys/src/libdisk
• sys/src/libdraw/klibdraw
• sys/src/libdraw/libdraw
• sys/src/libflate/libflate
• sys/src/libframe/libframe
• sys/src/libgeometry/libgeometry
• sys/src/libhttpd/libhttpd
• sys/src/libip/klibip
• sys/src/libip/libip
• sys/src/liblex/liblex
• sys/src/libmach/libmach
• sys/src/libmemdraw/klibmemdraw
• sys/src/libmemdraw/libmemdraw
• sys/src/libmemlayer/klibmemlayer
• sys/src/libmemlayer/libmemlayer
• sys/src/libmp/libmp
• sys/src/libndb/libndb
• sys/src/liboventi/liboventi
• sys/src/libplumb/libplumb
• sys/src/libregexp/libregexp
• sys/src/libs
• sys/src/libsec/klibsec
• sys/src/libsec/libsec
• sys/src/libstdio/libstdio
• sys/src/libString/libString
• sys/src/libsunrpc/libsunrpc
• sys/src/libthread/libthread
• sys/src/libusb/build
• sys/src/libventi/libventi
• sys/src/libz/build
• sys/src/libz/regress
• sys/src/libz/vendor
• sys/src/regress/regress
• sys/src/sysconf

Since we use json files to guide the build, we should give them a bit more love:

• replace .. inclusions with absolute paths (/ is the $HARVEY dir): so we can move folders easily
• inherit CFlags whenever possible
• make architecture-dependent paths depend on $ARCH (see core.json).
  Requires little changes to build.go
• use environment variables in Pre/Post scripts when appropriate (eg here and here)

We should remove all code that we are not going to maintain.

For example, are we going to include abaco in Harvey? What about libhtml?

Since we need to focus on a working core system we have to postpone the porting and modernization of some valuable tools that we inherited from Plan 9.

To clean up (and to clearly define) our core system, without loosing the connection with our glorious past, we need to move such valuable tools to Harvey-OS/legends, where their portings will be addressed with a lower priority.

Each tool should be moved with related documentation and manual pages in a directory tree resembling its original location.

Man pages references are outdated.

Expected behavior

Name of the operating system should be harvey
All links are working

Actual behavior

References to Plan 9
https://sevki.io/harvey/sys/man/1/acme references to sam, sam https://sevki.io/harvey/sys/man/1/sam doesn't exist
Outdated app links are still in the pages

Steps to reproduce

• https://sevki.io/harvey/sys/man/1/0intro
• https://sevki.io/harvey/sys/man/1/sam
• https://sevki.io/harvey/sys/man/1/acme

As part of the move to the new BUILD system we need to install the BUILD files in the right place.