There are a few Qubes specific configuration files such as: - /rw/config/qubes-bind-dirs.d/50_user.conf - Qubes-Whonix specific /rw/config/whonix_firewall.d - and a few other examples.
/rw is a non-standard folder. I think we can standardize this a bit. Examples: - /usr/local/etc/qubes-bind-dirs.d/50_user.conf - Qubes-Whonix specific /usr/local/etc/whonix_firewall.d (/usr/local is stored in /rw anyhow.) I don't propose abolishing existing implementations using /rw. - It would suffice if we keep this in mind for new developments. I.e. if some new Qubes functionality wants provide TemplateBasedVM specific "/rw style" settings, make that '/usr/local/etc/...' instead. - We could add parsing /usr/local to existing components (such as qubes-bind-dirs etc.). - Best to keep it backwards compatible, i.e. to keep parsing /rw/ for bind-dirs etc. Why? - /usr/local is an FHS standard. [1] - Other applications support /usr/local/etc. (Search engines say so.) (corridor does.) - For users it's best if it's kept uniform rather than having a standardized and Qubes specific location. - If feature requests are made / patches are proposed against third party applications (let's say for example against onionshare, Tor Browser), then it is more likely to have a request for the standardized /usr/local rather than Qubes specific /rw folder accepted. What do you think? Best regards, Patrick [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/c6456f2b-61bd-88a1-788e-65f792a333dc%40riseup.net. For more options, visit https://groups.google.com/d/optout.
