Dear intrigeri,
> I'll mention a few issues below but this will
> need a full review by our technical writers at some point (and when
> we're there you'll want to follow
> https://tails.boum.org/contribute/merge_policy/#submit).
Thanks for the constructive (and rapid) feedback, and for emphasizing that the style of the wiki should stay consistent. I must confess most of my previous experience in technical documentation has been in a field in which the passive voice was heavily overused, to the point of sounding pompous at times. (I've just done it again...) I'll keep an eye on it in the future :)
> I think this approach is good enough for a first iteration if, and
> only if, there's a solid plan to come up with something better soon
> after, because this approach has a few serious issues that I don't
> want to see in Tails for more than a major release cycle (~3 months):
Absolutely, this proposed GNOME autostart hack of mine was purely intended as a very quick fix to temporarily deal with a few users concerned about JavaScript being (re)enabled at every boot (since there are enough 'duplicate' and 'rejected' tickets about this tedious matter in our Redmine already. )
> - It makes the doc unnecessarily complicated for the vast majority of
> users who'll have to skip the added tip.
My first instinct was just to document the creation of a bash script under ~/Persistent, that would run at boot through by means of a .desktop autostart file. I figured, however, that if a user were able to do that, he/she wouldn't need my tip in the first place.
> Now, our next major release is scheduled for March 6, so you have
> plenty of time to implement something better :)
Out of your proposals from last week, I think a separate configurable GUI option in the Configure Tails Persistence dialog, such as "Torbutton security slider setting" may be the most future- and upgrade-proof from a developer's point of view. I'll get out my developer hat and just focus on this from now on. :)
> I believe the same result can be achieved with one single command
> (instead of 3) and without the $_ bashism:
>
> install -D --mode 0700 /dev/null \
> /live/persistence/TailsData_unlocked/dotfiles/.config/autostart/torbutton.desktop
I agree, using install is wiser. The less bash 'punctuation' the better, it can make even file manipulation look obscure and downright suspicious to those who don't work with linux.
> I think we use "start" instead of "boot", please check the terminology
> we commonly use elsewhere in our doc. Also, please avoid passive voice
> and technical details that are not needed (e.g. I bet most users don't
> know that "the amnesia user" is themselves, so "you" would be more
> straightforward to understand).
Agreed, I'll work on my style to make more succinct and match the rest of the wiki.
> I don't get it: you're calling bash only to call echo, and the command
> output redirection is outside of the argument passed to bash -c.
> Either we need bash to do the ">" (and then >prefs.js must be passed
> to -c) or we don't (and then we can drop "bash -c"), no?
Both the script to generate the .desktop file, and the Exec= value itself are very convoluted, I concur. They're the product of far too much testing and tweaking to get around the hideous limitations imposed by Gnome's .desktop launchers.
Normally I'm a real fan of scripts that can be understood at a glance, but I had a terrible time trying to get a launcher do something as simple as reliably echo out a multi-line file. The spec for launchers is so limited that even wrapping a command with a long path to avoid deforming our wiki doesn't appear to be supported. Having to escape single quotes within nested quotes felt so hacky, that at one point I was ready to change course and just instruct a user to put bash script in ~/Persistent and autorun that. I guess launchers are designed to be launchers, and not scripts, so my desire to be 'clever' may have been too much of a good thing.
Let me know you'd like a polished version of this 'tip' to be included. In any case I'll prepare a good dev/vagrant build environment for myself on Stretch and get to work on a proper Persistence solution that 'just works' for our next major release.
As always, any comments and suggestions are much appreciated :)
synthe
