What next?, Big picture

[James Browning]

On Saturday, June 28, 2025 6:55:15 PM Pacific Daylight Time Hal Murray via 
devel wrote:
> This is what I've been thinking about.
> 
> What do you want to do and/or what should we work on?
> 
> ---------
> 
> 1) Convert everything to Go or Rust
>   From recent discussions, this seems to be on the back burner.
>   I'd like to learn more about Go, but don't have a good plan/excuse.
>   Does waf support Go or Rust?
>     Is there some utility (ntpq?) that we could convert to Go?
>   There is NTP work in Rust.  I haven't investigated.

waf seems not to support rust or go as of waf-2.1.6 (which is newer than what 
we have, wse should upgrade).

I tried porting bits and pieces to go and/or rust; then I got frustrated and 
quit.

There is also NTP work in go. I have not investigated much and forgotten all 
of it.

> 2) Port to Windows
>   I know next to nothing about Windows.
>   Anybody know anything about POSIX on Windows?
>   Is there a good book/whatever to get started?
>   Does waf work on Windows?
>   Does Gitlab CI have a Windows option?

MS Windows only has POSIX as a shill for more money.
I am unaware of any specific books for MS Windows.
waf does work on windows, our code using it does not.
I am reasonably sure I remember that GitLab has MS Windows CI runners.

> 3) I'd like to build a fast server.
>   (It's just the sort of hacking I like to do.)
>   A server with nothing else is actually pretty simple.
>   With threads, a good workstation can keep up with a gigabit link.

https://github.com/mlichvar/rsntp.git exists, and I do not grok it.
Might be worthwhile to make the packet former as an h file.

> 4) Split up ntpd
>   Client, Server, info/monitoring, refclocks
>   One layer deeper, this means using threads
>   and separate sockets (and port numbers) for each server
>   so they don't need to use the main socket (port 123)

None of them should need port 123 if packets are selectively port forwarded.
We could us rsntp (above) for the super-majority of traffic.

> 5) Clean up info/monitoring
>   I don't have a detailed plan.
>   I think I want to put the data into shared memory.
>   I think we need a file to describe the data
>     and programs to turn that into a header file
>     and whatever ntpq needs

JSON schema j/k. I think MRU and clocks should be two separate things.

> 6) Clean demo/sample SNTP client
>   I'd like a clean, well documented sample SNTP client that people can copy
>   The idea is to try to reduce the crap that servers have to support.
>   [Probably separate from our main code.]

What languages and features were you thinking of?

I should read the NTP BCP.

> 7) Testing/support plan
>   It would be great if we had a list of things to test before a release
>   and/or a list with dates and names when they were last tested.

If we split up ntpd (above) then we should be able to build regression tests 
for the remote and reference clock services. I have little doubt that the 
center of the mechanism will be annoyingly opaque.

I should rewrite the seccomp handling code, but not this week. I have this 
head canon where it would have a config file command and load the text list of 
syscalls from a file and incrementally lock down the server.

It would be nice to have a test build that quickly hits all of the corners for 
seccomp instead of having to wait for everything to happen naturally.

I think it would be nice if I could figure out how to properly test the MS-
SNTP code. 

Patience is a virtue, which is why I have none.