I implemented ripoffline(3) in NetBSD and it shipped in -8. It now transpires there were a few problems with the implementation, mainly in regards to screen resizing, which is an extension to POSIX, but supported by ncurses and PDCurses.
Many improvements have been made with regards to compability with NetBSD and the others, but there are the following caveats:
- NetBSD will only resize stdscr, curscr and virtscr windows (like PDCurses)
- NetBSD clears the window when resized
- NetBSD will re-size and re-position the ripped off lines (like ncurses)
- NetBSD will not change LINES when ripoffline is called and may offset stdscr to it's relative position on the screen. This means that portable application should check getbegyx and getmaxyx for the size and location of stdscr.
The expectation is that the client will re-draw all windows, including ripped off windows on a KEY_RESIZE event. It's also expected that the client will re-size any other windows as it has a clearer idea of where things should be on the screen to it's proportion rather than curses guesstimating.
So finally I've moved all services from my old server to my Christmas Xen box! This was not without problems due to the fact it had to run NetBSD -current
- gcc toolchain is broken for some packages which affected running any PHP build
- clang toolchain was broken for my config (USE_SSP= yes and CPUFLAGS+= -march=core2)
- clang compiles as a whole were broken due to a recent efiboot import
In hind-sight, I could have had the box up and running a lot sooner if I used NetBSD-7 guests (or maybe just a NetBSD-7 build box), but no, I just had to get -current running. It offers more than -7 and prior exerience told me that tracking -7 was very problematic ... but that could have been due to my settings and wanting to compile everything with clang. I've currently got 3 -current images there now ... the Xen DOM0, the actual server itself as Xen DomU (without any compiler or tools) and another Xen DomU which just builds stuff for other guests to use.
Anyway, the box itself is now up and running and all relevant services have been moved to it. During this move, I decided to modernise things a little and setup HTTP/2. If you're reading this then it's working :) As such, I've re-directed all basic HTTP traffic to HTTPS and it does seem to load a lot faster. One side effect of this is that I've stoped using my own self signed certificates and I'm now using the nice Let's Encrypt service. pkgsrc users should use the py-certbot package and don't bother searching for any letsencrypt package as it's been renamed. I found this quite confusing as there was no reference to the rename in pkgsrc I could find and wasted a little time on it.
But now it's live I can finally look into bringing online some other development utilities to play around with as the server has a lot more room to grow :)
After starting the year with curses work, I decided to do some more!
Currently we lack Soft Label Key functions as specified by POSIX. What are these? Glad you asked! Soft Label Keys ripoff a line from the bottom of the screen and allow for up to 8 keys to be displayed there. You can define labels for them, colours, etc.
"BIG WHOOP!" I hear you say. "My app already does this, why should I care?"
Because SLK also works with the terminfo database to work out if the terminal natively supports labels (via plab_norm, label_on, etc)! This means a line doesn't have to be ripped off from the screen so no real-estate is lost. Sadly, no terminal actually seems to support these markings. But if one is ever made, it should work fine.
Now, not many curses apps actually use the SLK functions, probably for this very reason. But some do, and it is a standard so I've coded NetBSD to support this natively.
Sadly, this has uncovered a bug in the NetBSD curses library where cursor movement in a one line window at the bottom of the screen appears to push the window up. This is very visible with SLK and will have to be fixed for any apps that actually use it, but the SLK implementation itself is sound as resizing the terminal forces a redraw and it looks fine.
So over the holidays, I managed to get in some good quality family time and find some time to work on some Open Source stuff. I meant to work mainly on dhcpcd, but it turned out I spent most of my time working on NetBSD curses library so that Python Curses now works with it. Now, most people reading this blog may not care much for NetBSD or for curses, but it's important because ncurses is used pretty much everywhere by default ..... aside from NetBSD. And most readers should know, I go out of my way to promote interoperable software even when it's at a detriment to my own projects. That's just how I roll.
There is a apparently a thing called PD Curses but I don't know anywhere that actually uses it by default. If you know, please email me @ email@example.com or tweet me. I do know that the pkgsrc curses framework supports it.
And this is the thing I'm currently doing. As NetBSD curses supports more POSIX functions (and a few ncurses extensions, sadly) more and more packages now work alongside NetBSD curses, so I'm plowing through pkgsrc again moving things to the curses framework. This is important, because there is logic in devel/ncurses to use NetBSD curses when passing certain criteria, but sadly this always brings ncurses as a possibility to be linked or it's header used, both of which are quite bad for NetBSD curses so there is a method to my madness.
One interesting thing though is that since I started comitting my curses patches, it turns out that Sabotage Linux is using NetBSD curses and made it portable. I'm chatting with one of their devs and we're starting to merge of a few of their patches back into NetBSD.
So one of the main features of dhcpcd was the ability to add and remove addresses and subnets in accordance with interface preference and state. This worked very well in Linux, both for IPv4 and IPv6.
When I discovered FreeBSD and then NetBSD making dhcpcd work with the same features provided troublesome. For the IPv4 case, we needed to patch the kernel so that IFA_ROUTE remained sane. For the IPv6 case it was a lot more complicated as parts of the IPv6 stack rely on the kernel processing Router Advertisements instead of a 3rd party tool. Working this out was a lot more time consuming and complicated, but we got there with minimal fuss!
So as of now, dhcpcd can fully replace the NetBSD and Linux in kernel Router Advertisement handling code.
But why was I right after all these years? Because quite a few knowledgeable NetBSD folk assured me that the kernel was fine and it was likely dhcpcd at fault. As it turned out, it really was the kernels fault.