Jan 12 2021
I am not sure sdwdate-gui would be a strong enough notification if networking was actually blocked if sdwdate did not succeed yet.
Jan 9 2021
This was implemented. Now using python3 requests.
No longer required. Was implemented through te_pe_tb_check enhancements.
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.