ng0 <n...@infotropique.org> writes: > 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.
The top(1) command tells me that tor is taking up just short of a gigabyte of RAM. I haven't tried disabling the --enable-expensive-hardening flag, yet.
signature.asc
Description: PGP signature
