Stratum 1 microserver HOWTO

[Paul Theodoropoulos]

On 8/1/2018 2:41 AM, Eric S. Raymond wrote:
> OK, I'd be open to adding some clarifying visual elements.
> At this point you probably need to study up on asciidoc to know what is
> possible.
gack. I typed 'man asciidoc' and of course it's not installed by default 
in debian. So I went to install it, and was presented with:

0 upgraded, 219 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,112 MB of archives.
After this operation, 1,903 MB of additional disk space will be used.
Do you want to continue? [Y/n]

I'll have to pass on that for now, but will take a look online and see 
what I can learn.  =\
> Not a bad idea in itself, but we don't have the primitives for it
> available, and can't get them without deopping to raw HTML/Javascript.
> Which would open up several huge cans of worms around CSS and
> Javascript portability.  Life is too short for browser-specific hacks;
> I want to stay out of that swamp.
That's fair. I'm willfully ignorant of most things html, so knowing what 
is and isn't straightforward is a mystery for me. As above I'll do some 
reading up on asciidoc to at least temper my expectations of what 
is/isn't possible.

> But kill portability to no-window-manager installations of Raspbian. I 
> don't
> like the tradeoff here; I think it's more important to mimimize the complexity
> of the installed image, and its power budget. I actually want to go in the
> opposite direction, stripping down the image further.
I'm unclear here. All the Etcher app does is burn the bare image to the 
sd card. I'm not suggesting eliminating the cli instructions for doing 
so,  just a small optional component that can shave a chunk of effort 
cli that isn't really 'reusable' in the rest of the instructions. We 
don't do anything to the Raspbian image before first boot, i don't think.

> My design choice here is to supply just enough detail for 
> troubleshooting - e,g.
> so that the configuration is not opaque to the user abd he has some recourse if
> things don't go perfectly.
Got it.

> I don't see multiple edits on the same file as much of a barrier, 
> myself. In
>> terms of logical flow I think it works better. Editing the same file
>> multiple times can be instructional in itself - 'oh yeah, i remember this
>> file, the syntax looks familiar, I see how this modification fits into it'.
>>
>> As above I may be an outlier.
> Let's do the easy visual polish first and then revisit this.

Certainly. I'm not married to any of this - the reality is that the 
howto as it is right now works just fine. There are a small handful of 
confusing parts which are mostly due to formatting and ordering, which I 
continue to poke at (it's a very long document, so i have to focus in 
chunks). There are certainly 'cost'/benefit arguments at every juncture 
of this.

-- 
Paul Theodoropoulos
www.anastrophe.com