#djbwares — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #djbwares, aggregated by home.social.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Not to be confused with #daemontools, a different (and older) piece of software entirely that is approaching 30 years old, still going, and probably really hard to perform a supply chain attack on.
-
Excellent.
Yes, the latest released versions are supposed to be a version behind the actual development source. I freeze the source, do a binaries release, and start a new development version.
So #redo latest binary release is 1.5, and #nosh is 1.41.
#djbwares is at version 12, with version 13 under development. I must have forgotten to update the WWW page.
-
Early results are not promising. I've had a handful of HEAD requests in the past day. Only 2 appear legitimate, in that they hit genuine page URLs. The others were attempts to exploit WordPress vulnerabilities.
-
Early results are not promising. I've had a handful of HEAD requests in the past day. Only 2 appear legitimate, in that they hit genuine page URLs. The others were attempts to exploit WordPress vulnerabilities.
-
Early results are not promising. I've had a handful of HEAD requests in the past day. Only 2 appear legitimate, in that they hit genuine page URLs. The others were attempts to exploit WordPress vulnerabilities.
-
It makes me think that there's one well-behaved 'bot drowned in a sea of ill-behaved ones.
I'm just instrumenting #djbwares httpd to log GET and HEAD differently. I wonder what I'll see.
-
It makes me think that there's one well-behaved 'bot drowned in a sea of ill-behaved ones.
I'm just instrumenting #djbwares httpd to log GET and HEAD differently. I wonder what I'll see.
-
It makes me think that there's one well-behaved 'bot drowned in a sea of ill-behaved ones.
I'm just instrumenting #djbwares httpd to log GET and HEAD differently. I wonder what I'll see.
-
A truly universally portable #clockspeed is probably impossible. It has only recently become more than amd64-only. (AFAIAA, I'm the only one who has done the work to add another ISA.) Even then, it makes specific assumptions about the processor that aren't necessarily true (and which are called out in the manual, q.v.).
http://jdebp.info/Softwares/djbwares/guide/commands/clockspeed.xml
-
There are a much smaller number of people doing SVCB lookups, too. But, interestingly, they are doing them wrongly.
And with a direct correlation to some other abuses.
Which does make me think that, in an ironic twist, it is the bad actors running robot vulnerability probes and scrapers that are the early adopters of SVCB, here.
-
This does make you the second person in the world (if you picked up the source after I put it in yesterday) who can run
dnsqr https google.com
or even
dnsqr https jdebp.info
I didn't think that people were using this, it only having been accepted in November 2023, but I discovered a few lookups in my logs.
-
A bonus top tip for today:
'\376' will not compare equal to a character in memory with the value 254.
This is not assembly language, where one can compare an 8-bit byte with an 8-bit constant and have it just work, willy-nilly.
That would be crazy.
-
Looking up www.bing.com. nowadays involves dnscache looking up intermediate domain names in org., com., net., and info.; the cross-dependencies of which regularly exceed dnscache's nested gluelessness limit above which it switches to a slower resolution algorithm.
Some quick tests indicate that raising this limit from 2 to 3 improves matters.
So this will be in #djbwares 11.
-
@JdeBP I can confirm that redo-1.5, djbwares-11, and nosh-1.41 build packages just fine on both #FreeBSD 13.5 and 14.3.
Build logs on 14.3 in case you end up spotting something interesting:
- redo-1.5: https://gist.github.com/ermo/98d627c15c7768e16c42d460356bbd7e
- djbwares-11: https://gist.github.com/ermo/238af242324aabca481bb9ebd37e1ff4
- nosh-1.41: https://gist.github.com/ermo/166ecefe1599104e668cf7dafd833263 -
That may well be useful.
#redo version 1.2 (sic!) is in the #FreeBSD ports tree. I was just talking to @schmonz about the state of that port and how I have no real way to let the person behind it know that it's in very poor shape.
Neither #djbwares nor #nosh are in the FreeBSD ports tree. Presumably there are people working on ports, but that one of them was a decade ago an undergraduate on the other side of the planet shows the kind of barriers in place here.
-
I actually looked for contact details for Po-Chuan Hsieh, for the FreeBSD port, so that I could let xem know how messed up that port was; as I noted before. But there's only a wildly (a decade) out of date LinkedIn listing and an opaque FreeBSD account.
The Parabola packaging of redo is several versions out of date, and has the pre-pre-Brexit URLs. Arch is on 1.4 at least but using the pre-Brexit URLs.
I don't even know about Void, Hyperbola, et al.
-
I think that you possibly hadn't noticed before because it wasn't NetBSD; but now I've ported all three of #redo, #djbwares, and #nosh to NetBSD (testing on a non-amd64 architecture, no less!), as you've probably seen over the past few months. So now there's a system for building #NetBSD packages alongside Debian's, FreeBSD's, and OpenBSD's.
-
I'm doing #djbwares 10 next; right now, in fact (although I need to make a trip to the shops).
When I put it out, that's a good intermediate step to try next. It will test that you have a working redo without being a massive build that builds hundreds of things (as is the case for nosh).
It has the same basic command workflow as for building redo. There's a new accompanying Guide that details building from source but there aren't any real surprises over building #redo.
-
You're the only name in the log. (-:
https://git.parabola.nu/abslibre.git/tree/pcr/jdebp-redo
I'm just giving the packagers (those that I know about and are easily contactable, at any rate) a tap on the shoulder before the rest of the world explicitly learns that #redo 1.5 is up.
https://jdebp.uk/Softwares/redo/
(Po-Chuan Hsieh of #FreeBSD is still using a URL that has not worked since Brexit. 17 million people voted that I should not have my domain name. (-:)
#djbwares 10 is next.
-
Right.
I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.
I'm running out of release blockers. (-:
-
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.
-
I hope that no-one is too inconvenienced, but to scratch my own itch I've made #taiclockd, in the upcoming new version of #djbwares, combined-stack capable.
i.e. one server listening on a single UDP/IPv6 socket should serve both IPv4 and IPv6 clients.
The original UDP/IPv4 flavour is retained as taiclock4d. But you shouldn't need it on #FreeBSD, #Debian Linux, #NetBSD and the like.
There is now ip[20] in several parts of the code, paralleling Bernstein's ip[4]. (-:
-
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.
-
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.
-
(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.
-
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.
-
I made the mistake of starting to learn about GEMINI from its Frequently Asked Questions document.
It's not aimed at people like me, who already understand the benefits and tradeoffs of static content servers. So it drives lots of points home, repeatedly, that I already know.
It's apparently aimed at the same sort of monoculture Chrome+Apache Think for HTTP that parallels the old BIND Think and Sendmail Think that #qmail and #djbdns were up against years ago.
-
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.
-
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.
-
It's a tale as old as Usenet: someone posts a war story; a bug gets fixed.
It's 2025. I suspect that DJB would agree that fake IP addresses used by Sandra Bullock in a movie 30 years ago should not actually work in real tools because of unchecked integer overflow. (-:
So I've patched ip4_scan() and this will be in the next release of #djbwares.
-
"Note that the original Qmail site is gone" says the #Dovecot doco.
A quick check confirms that http://cr.yp.to/qmail.html is still there and has been all along.
It turns out that the Dovecot doco writers didn't know where #qmail originated, and thought that http://qmail.org was its original WWW site. But a quick check reveals that even that is still there, too.
-
I have clarified the sntpclock manual slightly. This will be in the next release.
http://jdebp.info/Softwares/djbwares/guide/commands/sntpclock.xml
-
The good news was that I hadn't set it up to use ntpd. Checking, it turned out that ntp.conf was configured with NTP servers that no longer exist, anyway.
The bad news was I hadn't actually configured it with anything else. So I had to quickly install Bernstein clockspeed, and after about 5 spaced apart rounds of sntpclock $IPADDRS|sudo clockadd it was back in synch after I had got the time roughly right by hand in SETUP.