May 19 2020
May 14 2020
@Patrick No biggie wrt the paid developer to implement. I like your idea on the Qubes GitHub ticket, of posting an article on the website. I'll email you separately, to coordinate on that. Said website post, I'd like to accomplish two things: one, solicit user input on any/all UX work. Two, put out the call for paid GUI dev work.
ninavizz (nina eleanor alter):
ninavizz added a comment.@Patrick I am currently working on a funding proposal, to get the UX work required to get production-ready handoffs to a developer, created.
May 13 2020
@Patrick I am currently working on a funding proposal, to get the UX work required to get production-ready handoffs to a developer, created. The above was just a shared idea, to kickoff the conversation. My apologies for not being clear on that. I would like to work on a parallel proposal to get the development work done, to improve all of the Whonix GUI stuff; the time-sync widget menu, and the windows that enable deeper settings control.
I am not a GUI developer at this point so please don't wait for me to implement this. sdwdate-gui is from a time when Whonix had a contributor doing GUI development.
Apr 16 2020
Feb 16 2020
So... keeping an eye on user-needs as the priority driving this story: the list of "What needs doing" is ordered, below, as I see it:
Dec 23 2019
Nov 6 2019
This was done. If not, please create specific tickets where it isn't done.
Jun 14 2019
Apr 14 2019
Apr 12 2019
Apr 6 2019
Dec 7 2018
Oct 1 2018
Sep 20 2018
Sep 18 2018
Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).
Sep 12 2018
Sep 11 2018
Aug 15 2018
Aug 7 2018
In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.
And then configure NTP to connect only to that local NTP server.
Aug 6 2018
/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.
Yes, not readily accessible from command line.
The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.
From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.