I noticed this before the contribution entered master, so this message is not really a news.
To quote myself from earlier today:
<ng0> I think we should revert one piece of the tor hardened build.. 3
hours
uptime: 684.3 MiB + 753.0 KiB = 685.1 MiB tor
Comparison: my Chromium with 55 tabs open uses 2.2GB.
Private + Shared = RAM used Program
…
12.4 MiB + 1.1 MiB = 13.4 MiB vim
15.5 MiB + 959.0 KiB = 16.4 MiB Xorg
17.3 MiB + 5.6 MiB = 22.9 MiB guix substitute
22.8 MiB + 1.3 MiB = 24.1 MiB shepherd
26.7 MiB + 551.5 KiB = 27.3 MiB emacs-25.2
131.1 MiB + 6.2 MiB = 137.3 MiB .guix-real
732.7 MiB + 932.0 KiB = 733.6 MiB tor
…
uptime: 6:24h
Now I wouldn't consider tor to be problematic when this would be the
default for tor. But it isn't, and --enable-expensive-hardening is an
experimental function which is not enabled by default from upstream (as
all our recently added config options for tor (not sure right now if all
are experimental, but they are not standard).
Comparison, Debian running for a very long time (months) and using the
same config:
40.6 MiB + 486.0 KiB = 41.1 MiB tor
I'm convinced that removing --enable-expensive-hardening will improve
the situation, I have watched an VM with tor without this config switch.
Whoever needs or wants this switch can make use of the easy way to
create custom packages in Guix.
If someone else can confirm my observations, I'll prepare an patch.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
