My little login.conf(5) shim is working nicely on Debian Linux.
login.conf(5) is one of the things that #FreeBSD (and to a lesser extent #NetBSD) does better than Debian.
I'm testing the stuff on #Debian as I mentioned a few days ago. It is going fairly well so far. I'm now at the point of setting up some #djbwares services.
The new battery is now in, but of course the machine is now powered up and doing stuff.
It is a "Plattboj" from #Ikea, best before 2023 according to the blister pack. So I probably have a rude surprise waiting the next time that I power the machine off. (-:
I *could* publish the new #redo right now, as building #djbwares and #nosh with it has given it a fairly thorough test on Debian. Not that there was much scope for it going wrong given that it was already working on FreeBSD and NetBSD.
The good news is that with only a modicum of tweaking the long-pending new versions of #nosh, #djbwares, and #redo build on Debian Linux.
The bad news is now I have to do a lot of testing.
And I still haven't fixed the build machine's battery.
So whilst it is powered off because of the excessively hot weather, it has lost all of its firmware settings and has gone back to 2012 again. (-:
The partition that wouldn't clone contained the compiler and operating system, so alas there's going to be a jump in operating system support.
Fortunately, I already did the work of fixing old DJB K&R code to eliminate all of the warnings (from a 2024 compiler) that K&R C syntax will be going away when 2023 rolls around, when porting to #NetBSD. So using an updated compiler should not be too much of a problem.
Slowly I progress.
I've managed to clone most of the disc of the broken Linux build machine, and after a number of false starts (We are past the Age of DUET, it turns out.) have got the build machine booting with some replacement hardware.
It still needs a new NVRAM battery and is complaining about a "221" memory error, so I'm not out of the woods, yet,
But things are creeping towards getting the new #nosh, #redo, and #djbwares versions built.
<servicehelper> in a conf file and a launch helper have definitely worked, although I haven't re-tested in the past couple of years. My launch helper is just a script that knows how to invoke various commands such as initctl or system-control.
The irony, as explained on the FGA there, is that they could have made the #DesktopBus broker itself talk to multiple service managers and know what to do; had patches to do so not been blocked.
For best results, one has to turn off the Desktop Bus broker's own rubbish service launching and intercept and send all service launch attempts over to proper service management.
https://jdebp.uk/Softwares/nosh/guide/per-user-dbus-demand-start.html
https://jdebp.uk/Softwares/nosh/guide/commands/dbus-daemon-launch-helper.xml
https://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html
【nosh / 案件】今回は晩酌しながらお酒に合うお弁当を選ぶ！！【ころねの食レポ成長記録】
https://www.youtube.com/watch?v=w2Tfv9ru-KA
#youtube_InugamiKorone #ホロライブ #VTuber #バーチャルYouTuber #戌神ころね #ホロライブゲーマーズ #hololive #ゲーム実況 #ナッシュ #nosh
There are some things around the edges as yet not implemented or tested. I haven't tested the uhid or ugen realizers yet. But #NetBSD looks the same as #FreeBSD in this regard, and I'm expecting that to be fairly trivial to fix if it just doesn't in fact work straightaway.
And there is still that known gap in the ifconfig command.
Nonetheless, this is a large part done of the porting of #nosh, #djbwares, and #redo not only to NetBSD but to a non-amd64 processor architecture too.
It doesn't look quite right on a 16:9 HDMI display with a 16 by 16 font. It lacks the pixellation and CRT blurring. And the cursor is wrong. So @ColinHaynes still has the better. (-:
But it's not bad for a non-X11 framebuffer Unicode-capable terminal emulator on a #RaspberryPi running #NetBSD with the #CommodorePET and BBC character sets.
(That was the BBC font. This is the #CommodorePET font.)
The various tools from #djbwares are operational and run happily as managed services, including local DNS service, some publicfile services, and synchronizing the #RaspberryPi's clock using Bernstein's sntpclock fed into clockadd.
A #nosh user-space virtual terminal being realized onto the HDMI display of a #RaspberryPi running #NetBSD.
The realizer is console-kvt-realizer, and the framebuffer was dumped to PPM format with framebuffer-dump (to be converted to JFIF using netpbm tools). The login screen is a ttylogin@vc3-tty service, managed by service-manager, and using login-envuidgid.
Yes, it is being multiplexed with two others, and has an input method layered on top.
As implied, the #NetBSD port of #nosh, #redo, and #djbwares is pretty much done.
NetBSD doesn't make it as easy to switch between process 1 programs as FreeBSD does, so the system manager is not tested. But many of the other tools from tai64nlocal, cyclog, and setterm; through login-envuidgid and envdir; to the service manager and console-tty37-viewer; have now been used in earnest.
There are known missing bits in #ifconfig and list-process-table. And UVT realizers are not tested at all yet.
Yes, I have been musing about setting up a GEMINI server, especially as GOPHER doesn't really do virtual hosting and is thus a bit poor when it comes to the #publicfile content model.
I've pre-prepared a gemini6d service bundle, but an actual geminid server to go alongside httpd is still a to-do item.
I first learned of GEMINI's existence only a few days ago.
I caused myself to waste several days with the #NetBSD port of #nosh by uncommenting NetBSD's supplied /etc/login.conf settings, to check that the code to use login.conf worked, without checking in too much detail what they were.
Someone had set the open file descriptor limit, in a vanilla installation the same as kern.maxfiles since NetBSD 10 ships with login.conf all commented out, down to just 128.
Very funny joke, Indy. (-:
https://cvsweb.netbsd.org/bsdweb.cgi/src/etc/login.conf#rev1.4
The not-very-secret GOPHER server is well on its way to being back up; and those of you who know GOPHER will soon be able to get the latest development source snapshots of #nosh 1.41 and #djbwares 10 again.
*Of course* it is a machine running those self-same nosh and djbwares to serve up GOPHER et al.. The last one ran #OpenBSD. This one is running #NetBSD, hence the recent porting work.
It's not in its intended location yet. But it is facing the Internet now.
https://www.wacoca.com/videos/2747671/kanata-hongo/ 本郷奏多の日常: テキーラ1本飲む #KanataHongō #Kanata'sHoliday #nosh #Vlog #Vlogger #YouTube #YouTuber #テキーラ #テキーラ1本飲む #俳優 #声優 #日常 #本郷奏多 #本郷奏多の日常
I've been talking about things coming in the next versions of #djbwares, #nosh, and #redo. You're probably wondering when, since COVID and Brexit and other things created a quintuple limbo.
There's a big hurdle of getting a Linux build machine, which has sat with a faulty DASD for some years, back up and running.
But there's a plan, and it's in motion.
One step is the not-very-secret GOPHER server with the development source snapshots coming back up.
This was not supposed to be when I was doing #NetBSD adjustments to #redo, #nosh, and #djbwares at all. That was supposed to be on the *next* #RaspberryPi.
This was *supposed* to be the point at which I checked that the #OpenBSD parts of the code, untested since before COVID Lockdown, still worked.
(There are a lot of changes in 1.41.)
This was *supposed* to be getting me a vanilla Pi in a non-fancy case running #OpenBSD, nosh, and djbwares; sitting in a corner quietly.
NetBSD, now.
The second attempt — coming soon — thus has promise. The errors were mainly the holes in the code that I'd left ready inside if defined(__NetBSD__) blocks, and hadn't coded for how NetBSD does things. I am from that experience expecting few problems with building #djbwares .
I'm doing half-hour-long backups at stages during the installation process, this time.
