Re: s6-ps

[Colin Booth]

On Sun, Jan 06, 2019 at 07:30:21AM +, Laurent Bercot wrote:
> 
>  - The execline library is required to build a few of s6's utilities
> (typically: s6-ftrig-listen).
>  - The execlineb binary is required for use of the !processor directive
> in s6-log.
>  - Some of the other binaries provided by execline are used by
> s6 utilities, for instance s6-fdholder-store.
>
Ah, good point. I was misremembering and thought s6-log processed the
command string itself but used libexecline to teach it how, similar to
s6-ftrig-listen's dependency.

Looking a bit closer, the one that's going to break the hardest for
people using s6 solely as a supervisor is s6-notifyoncheck since you can
inline a check program with the -c option. I'm not sure how many people
go that route who aren't already going to have execline installed, but
it's something that will definitely cause some ill will.
> 
>  "Recommends" is a mistake. Without execline, parts of the s6 suite
> of programs will break.
>
> --
>  Laurent
> 

-- 
Colin Booth

Re: Can s6 be enough?: was s6-ps

[Brett Neumeier]

On Sat, Jan 5, 2019 at 2:30 PM Steve Litt  wrote:

> So what do you all think? Is s6 a useful init system without s6-rc?
>

My 0.02 USD -- based on my experience of setting up a simple GNU/Linux
distribution from the ground up using s6, s6-rc, and s6-linux-init...

- s6-rc provides useful functionality: it is really handy, when defining
the way that the system should start up, to have bundles and oneshots; it
is also really handy to be able to start up or shut down groups of
processes via bundles.
- The cost of using s6-rc is negligible. As installed on my x86_64 system
with documentation, it consumes around 576 *kilobytes* of storage space. It
compiles and installs in substantially less than a minute. Learning how to
craft s6-rc service definition directories is no more difficult than
learning how to craft s6 servicedirs.
- You don't lose any capability provided by s6 if you also use s6-rc. You
can send whatever signals you want to the supervised processes by using
s6-svc directly.

So ... costs ~= 0, benefits > 0, to me the question of whether s6 is useful
_without_ s6-rc is kind of pointless.

I'm inclined to turn the question around: what leads you to want to avoid
s6-rc? Is there some other system that provides more benefits at lower cost?

Cheers!

Brett

-- 
Brett Neumeier (bneume...@gmail.com)

Re: nosh: User-space virtual terminal test and questions

[Jonathan de Boyne Pollard]

Guillermo:

The combination of vboxvideo with |console-fb-realizer| was explosive, 
I got a (guest) kernel panic.


|console-fb-realizer| does not employ the arcana of framebuffer I/O, it 
just using little more than the mode setting API and memory mapped I/O, 
so I'm initially going to lay that one at the door of the driver.  I 
have had poor experiences with it myself.  Try the |--80-columns| option 
(which prevents |console-fb-realizer| trying to switch to some of the 
more exciting high-resolution modes) and ensure that your driver exactly 
matches your kernel version.


I currently test |console-fb-realizer| on real hardware.  (-:

Guillermo:

I [...] managed to deal with the BSDness of the requirements on font 
and keyboard map files with the help of FreeBSD's SVN repository :)


For those reading this, there is a whole chapter in the _Guide_ on the 
multiplicity of places whence one can obtain fonts, keyboard maps, and 
input methods.  The toolset does not come with them for two major 
reasons.  First, it is a deliberate design decision to use existing 
formats and not require new ones be created from scratch.  Second, they 
come under a variety of copyright licences, and it is simpler to just 
keep those separate.  Quite a few of them are already packaged up for 
operating systems.  I discovered /yet another/ collection of input 
method files just recently ... in a Debian package.


Guillermo:

1) What is the proper way (if any) to switch between kernel VTs and 
user-space VTs?


|console-fb-realizer| does not have hot key chords for initiating KVT 
switching that get stripped out of input processing and enacted 
locally.  All such chords are sent down the input FIFO to a /user-space/ 
VT multiplexor.  It could have, as there is room for such a specialized 
type of actions in the keyboard map.  Since I need to do more work on 
having multiple keyboard maps in a single |console-fb-realizer| 
instance, I might look into it.  But at the moment 
|console-multiplexor-control| pointed at a KVT is the tool, and I am not 
going to hold off 1.39 specifically for this.  I was going to do that 
work in 1.40.


Guillermo:

2) Key combinations with Alt (e.g. Alt + f or Alt + b to move forward 
or backward one word on Bash) did not work with neither 
|console-fb-realizer| nor |console-termio-realizer|. Any idea why, or 
does this just happen to me?


I have an idea why.  I have put improving it on the to-do list. It's not 
you.  (-:


Guillermo:

3) More strangely, Ctrl + x (e.g. to exit from GNU nano) did not work 
with |console-termio-realizer|, but did with |console-fb-realizer|.


Control+X is ␘ (cancel, U+0018) which cancels an in-progress ECMA-48 
escape or control sequence.  This is documented in ECMA-48:1991 § 8.3.6 
and in § 4.3.5 of DEC's _VT520/VT525 Video Terminal Programmer Information_.


|console-termio-realizer| decodes its input with a fully-fledged ECMA-48 
decoder, that implements the DEC/ECMA-documented behaviours of both ␘ 
and ␛ on the decoding state machine; rather than with a perennially 
incomplete collection of ad-hoc pattern recognitions as 
|console-ncurses-realizer| does.  It's the same decoder that 
|console-terminal-emulator| uses for output.  You can see ␘ in action 
with the new |console-decode-ecma48| tool in 1.39, which also uses the 
same decoder.  Type in an incomplete CSI sequence by hand, and cancel it 
with ␘.  It will be discarded.  The same will happen if you print one 
and cancel it, as output to the terminal emulator.


Although it would be entirely legitimate for a terminal to send ␘ in the 
middle of (say) a DECFNK control sequence in order to cancel it, it 
would be unusual, so I'll add another exception to ECMA-48 decoding for 
this, that |console-termio-realizer| can select.


ECMA-48 is of course nothing to do with the input protocols that 
|console-fb-realizer| speaks with its input devices.


Guillermo:

4) With |console-termio-realizer|, green is blue and blue is green :D 
Not with |console-fb-realizer|, though.


Part of my usual Z shell prompt is green, so I am confident that I would 
have noticed it being blue in error.  (-:


What terminal type is |console-termio-realizer| outputting to?  Is this 
a GUI terminal emulator with a colour palette that has been altered from 
the standard colour set?  Is it a 24-bit-colour-capable terminal?  Use 
|console-control-sequence --foreground blue|console-decode-ecma48| from 
version 1.39 on that terminal.  What do you see?  SGR 34?  SGR 38;5;4?  
Or SGR 38;2;... ?