Hi,
AK wrote (01 Jun 2014 17:17:02 GMT) :
> OK, but note this from the htpdate website [1]:
> "!!! no development on the Perl version is done anymore !!! "
Thanks for the pointer.
In practice, we've forked it years ago, after sending pull requests to
upstream, who never replied. The version we're using works very well
for us. So, I'm neither overly concerned, nor convinced that having
this thing maintained upstream would be a game-changer.
> "Be aware that the script makes a step in time and some programs (e.g.
> database) do not always appreciate a step backwards in time. The C
> version of htpdate doesn't step but adjusts the time smoothly."
> So it is no longer maintained by upstream, and it doesn't adjust the
> time smoothly. I guess you don't want to always adjust the time
> smoothly since you want people to be able to get started right away,
Right.
> but I think that if their clock is already close enough, it is better
> to adjust smoothly (built in kernel feature as I understand it).
Why?
> Also, C can run slightly faster (not sure if it's significant)
I believe that the Tails' time syncing process is not CPU-bound.
I could be wrong, but I would be surprised if the time spent computing
things took significantly more than a few percents of the process.
> For memory protection, I would suggest using kernel hardening such as
> PaX from grsecurity [2].
Sure, this would be good. I suggest refering to the discussion about
it, on this mailing-list, a couple months ago, to get an idea of
the challenges.
But still, having enough band-aid to hope one is able to stop the
bleeding is not good reason to create injuries in the first place :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
