Saturday, December 30, 2017

Git and markdown and CD0

Git and markdown and CD0

Sir Russ the Just prevails upon me: I'm increasingly using Git for projects.
What's so great about Git?

 Git

Not personally stuck on any one content manglement system. (The acronym CMS is a whole other story.) But Git seems to have advantages for collaborative coding. Hearing the hype, my radar perked up when the GitHub guys offered a free intro class (now five years ago). 

At work we lean primarily on Subversion. But Git looms large. My teammate, the Nomad, gave me his take on the matter. For him, Git works better when you need to branch, test, merge, and commit remotely. (So maybe that helps nomadic life.) The corporately sponsored GitHub server is available to anyone with credentials, not merely our division (and with no special dispensation from our over-worked local devops team). Normalized access is a major plus. Anyone on my team can use it too.

Markdown

Speaking of remote operation, at work we also use Confluence. This popular documentation tool must be incredibly chatty. I haven't analyzed the traffic. All I can say is that (for me, 100% remote) it's ssslllooowww with a capital SSS. (Evidently not slow for those at HQ.) If Confluence pages under the covers were plaintext (HTML or other markup), we could RSYNC to/from the server and make changes easily. But Confluence wants to be interactive by way of your web browser. (Something about hammers and nails and "everybody has Internet Exploder", so what were Confluence designers thinking?)

I don't know what I don't know about Confluence. Gentle reader, please be gentle if you have myriad clues that I lack about the wonders of Confluence and how it can be made to work better. Maybe you'll say, "yes, Rick, you can RSYNC from/to Confluence".
Meanwhile, enter Markdown.

Another nudge from Russ is to get me free from the talons of Google, specifically their documentation service. (Let's not talk about the fact that this post has its genesis on another Google property.) Russ says I should use markdown for project docs. I offered no resistance: markdown is plaintext, it's portable, it's simple. At work, markdown docs on the corporate GitHub server are a refreshing alternative to Confluence pages. For hobbies, I find myself converting Google docs to markdown as time allows.

CD0

All of this comes to a head because NORD has a "GitHub project" presence which is now getting more TLC. This is where I'm burning most of that doco conversion time, moving files from Google Drive to GitHub. But being GitHub, this is also where the non-doc files have been mirroed for a long time. The effect is a convergence of doc files and operational files into a common space. Good!

What's lacking is a spreadsheet, or something that looks/tastes/smells like a spreadsheet, which can serve both for documentation and operation. As NORD evolved, it helped to have a place to publicly list what packages are current. (NORD eschews formal package management, which would include inventory, for the sake of sticking closer to the individual package sources.) Using the common spreadsheet as a reference, one can get a local NORD installation up to date programmatically. Markdown does support tables, so that might be a workable alternative to a proper spreadsheet.

What's CD0?

NORD is comprised of a core operating system with "optional" packages drawn in on demand. The optional packages are built with Chicory so they can reside anywhere, but as a starting point there are collections under /opt named CD1 through CD5. (Maybe more later.) The naming is intentional because eash collection could literally reside on a CD or DVD or in an ISO-9660 image. In any case, separate filesystems is ovten reasonable.

CD0 is a special case. The packages in CD0 are the Chicory build of core packages (normally built with CSCRATCH). CD0 doesn't have the entire core package set, but by design has enough packages for "rootstrapping". Supplement packages from CD0 with those from CD1, CD2, CD3, and a fresh NORD core system root can be derived. Once the new NORD core system has been built, CD0 is no longer needed.

Summary, only tangential to Git and Markdown, the current CD0 set is ...

  • autoconf-2.69
  • automake-1.15
  • bash-4.4
  • bison-3.0.4
  • bzip2-1.0.6
  • coreutils-8.27
  • curl-7.54.1
  • dash-0.5.9.1
  • diffutils-3.6
  • file-5.31
  • findutils-4.6.0
  • flex-2.5.39
  • gawk-4.1.4
  • gettext-0.19.8
  • grep-3.1
  • gzip-1.8
  • libtool-2.4.6
  • m4-1.4.18
  • make-3.79.1
  • nano-2.8.6
  • ncurses-6.0
  • patch-2.7.5
  • pdksh-5.2.14
  • readline-7.0
  • rsync-3.1.2
  • screen-4.6.1
  • sed-4.4
  • sharutils-4.15.2
  • tar-1.22
  • texinfo-6.4
  • wget-1.19
  • which-2.21
  • xz-5.2.3
  • zlib-1.2.11

That's 34 packages. Some of them are behind current releases for one reason or another. With Chicory, both old and new can co-exist on the system, but this set is intended for rootstrapping. Now to put the list into table form.

-- R; <><




1 comment:

  1. I use git and -stash- make that Bitbucket, Jira, Jenkins and Confluence. I hate Confluence. Way too much effort for too little product. The others, I like a lot.

    Mark my words, the dominant product for group-sourced documents will be (probably already is) Jupyter Notebooks. Current UI is Jupyter Lab. I'm sure before long Jupyter Hub will become the norm.

    In Jupyter notebooks, content is a list of cells. A cell can be a markdown cell OR it can use one of an arbitrary list of kernels to execute code in real-time in the cell. By default, python2 and 3 and bash are there, but there are HUNDREDS of kernels available for Jupyter. Want to have one of the cells execute fortran? There is more than one fortran kernel to choose from. Running R in a cell is commonplace.

    There are hundreds (thousands maybe) of github projects that are actually jupyter notebooks. Fork or clone them off to your own space, and you can run them on github!

    Think of standalone Jupyter notebook as your baseline CLI environment.
    Jupyter Lab lets you use and manage Jupyter Notebooks in a chooser-type environment.
    Jupyter Hub gives you the ability to spawn notebooks into containerized and isolated environments during their run.

    OReilly and associates has embraced Jupyter as their publishing platform going forward.

    ReplyDelete