Re: nosh: User-space virtual terminal test and questions
El dom., 6 ene. 2019 a las 8:27, Jonathan de Boyne Pollard escribió: > > > The combination of vboxvideo with |console-fb-realizer| was explosive, > > I got a (guest) kernel panic. > > > [...] > so I'm initially going to lay that one at the door of the driver. Yeah, I'm suspicious about the kernel module too. I didn't spend too much time with this, I just blacklisted the module for the console-fb-realizer tests, which gave me the VESA framebuffer device. But I thought I should mention that it happened in case anyone else wanted to try that, or had not experienced it. > Try the --80-columns option > (which prevents console-fb-realizer trying to switch to some of the > more exciting high-resolution modes) The option is not present if console-fb-realizer is built on [GNU/]Linux, right? 'console-fb-realizer --help' doesn't show it, and the C++ source file seems to have the relevant code contained inside an #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__OpenBSD__) - #endif block. > > 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. Oh, I don't expect nosh to ship font and keyboard map files. That was a humorous remark about them either having to be in a BSD-specific format, or in a format that a BSD program (vtfontcvt) outputs. > First, it is a deliberate design decision to use existing > formats and not require new ones be created from scratch. That's fine. > > 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. > [...] > console-termio-realizer decodes its input with a fully-fledged ECMA-48 > decoder, [...] So, how does one get the control character delivered to the application? Is it possible with console-termio-realizer? > > 4) With console-termio-realizer, green is blue and blue is green :D > > > Part of my usual Z shell prompt is green, so I am confident that I would > have noticed it being blue in error. (-: I noticed it with GNU ls's colorized output (directories showed up green and executable files showed up blue), and Bash's prompt, which also happens to be green and blue, and looked reversed. This is the value of PS1: \[\033[01;32m\]\u@\h\[\033[01;34m\] w $\[\033[00m\] > 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? Straight to a kernel VT, and I don't think the color palette is changed from the default. This is how I lauhched console-termio-realizer: /etc/inittab: us2:3:respawn:/home/guillermo/bin/start-termio-realizer /home/guillermo/bin/start-termio-realizer: #!/bin/nosh foreground sleep 1 ; vc-get-tty tty8 open-controlling-tty vc-reset-tty /lib/nosh/setuidgid -s user-vt-realizer console-termio-realizer /run/dev/vc1 (Yeah, that's van Smoorenburg init. Minimal setup for ease of troubleshooting, remember :) ) I didn't see a console-termio-realizer (or console-ncurses-realizer) example in nosh-bundles, maybe simple file descriptor redirections would have sufficed, but that worked, so... > 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;... ? I'd have to build in-development 1.39 for that. I'll post the result when I do that. Thanks, G.
Re: s6-ps
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
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
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;... ?
