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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
