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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
