Embed this notice:p: (p@bae.st)'s status on Monday, 08-Apr-2024 18:01:38 JST
:p:It really bugs me how often ntpd produces slightly out of sync clocks by trying to be overly clever with skew and with trying to not break software that relies on a monotonically increasing clock. If something breaks when the clock fails to increase monotonically, it's shit, I don't care if it crashes. I'd rather it crash so that I know to uninstall it.
So, I tried to do it "right" this time, but I am going with the strategy that works: run `ntpdate pool.ntp.org` after the net comes up and then periodically run it again from a cronjob. ntpd(1) has some warnings about how if you do it that way, you don't get the cool skew detection, and it should be the opposite
In other news, `cargo` is a total piece of shit and this should come as no surprise to me because Rust is a language made by children that have no idea what they're doing but every time I have to interact with software written in Rust, the compiler and the tooling find new ways to disappoint me. I should just get a bunch of RISC-V gear so Rust shit won't run and I don't run into problems like this. boxesallinarow.png
@istvan@p Does endianness matter? I have a Powermac G5 laying around but that can only run big-endian binaries. (I guess I can check Chimera's package search on the matter)
@istvan@allison Oh, holy shit. I remember that kernel option to swap the framebuffer's endianness, I bet it was for avoiding running the whole box with the endianness swapped.
@p Like cargo just thinks REALTIME should only ever increase similarly to MONOTONIC? Shit really ought to crash, although I could see that causing cases of data corruption.
@p@syzygy I think by default chrony sets the clock at launch and then drifts.
At least if I'm reading the manpage right, here with makestep 0.1 3 (which is given in the manpage, hence my guess of me not modifying the config) it adjusts by steps of 0.1 seconds unless it's bigger than 3 seconds.
@p@syzygy Which I'd say is the correct behavior, 3s being RTC drift over quite a long period of time, more than that and your clock is likely entirely off.
> I think by default chrony sets the clock at launch and then drifts.
Yep, this is what the docs indicate, this is exactly the behavior I want (and apparently they use the ethernet hardware timestamps). ntpd tries to guess at and anticipate drift and then jump to the target time in 250ms increments. As far as I can tell, it has never done that correctly, or those clocks would get *closer* together rather than one of them speeding up and one slowing down.
> it adjusts by steps of 0.1 seconds unless it's bigger than 3 seconds.
@p No, your memory deceives you. Newer PowerPCs are little-endian — and that is the architecture still supported by a lot of distros, unlike BE. 64 PowerPC CPUs could switch endian-ness too: https://en.wikipedia.org/wiki/PowerPC#Endian_modes That G5 just doesn't support it, at least I've never seen it done on real hardware and doing so would be trouble anyway as old Apple's OpenFirmware surely doesn't support that. ppc64le is even supported by the reference Go toolchain, again, unlike BE — which is supported by gccgo though, but there's little use in it as most modules do not support that anyway and you'd have to do a lot of work porting those too. I think I've even succeeded building gccgo for 32-bit PowerPC, which is no longer possible as it looks like some definitions got removed from gcc's source. You can in theory add those back of course, but like I already said — there'd be little use in it as most modules won't work as is anyway.
Unlike Rust BTW! Which works on nearly anything and the kitchen sink, here's the machine this instance runs on. And it's probably a relatively recent version even. I'm not even that sure that RISC-V machines aren't supported — they are probably worse supported than more mainstream architectures and have a similar problem — even more mainstream modules won't work. I have this problem on PowerPC too, e.g. ring is a pretty popular cryptography crate, but it can't even be built as is. IBM made a series of patches so it's possible for ppc64le and with a little effort I could make it build on this 32-bit machine even, but autotests still fail — looks like there are more underlying issues. I originally started these effort with intent to host libreddit — but as Reddit went to shit anyway, I've just given up :marseyshrug:
Yeah, that is fuckin' weird. @istvan just pointed that out.
> they are probably worse supported than more mainstream architectures
I am running regular-ass Slackware on my RISC-V chip and basically everything works. Less hassle than ARM, even, which surprised me: you'd think ARM would be ironed out in current year, or at least in a nicer state than RISC-V.