Re: [Tails-dev] [brainstorm] What are our public XMPP chat rooms useful for? (#17956)

[Austin English]

On Tue, Jan 5, 2021 at 2:41 AM intrigeri  wrote:
>
> Hi,
>
> (dropping my facilitator hat for this message)
>
> intrigeri (2021-01-03):
> > So, my question is:
> >
> >   What would we lose if we did not have any public chat room?
>
> > In other words:
> >
> >   What new problems would we face if we did not have any public
> >   chat room?
>
> I think we would lose:
>
>  - some of our soul and identity, i.e. "we work in the open"
>
>  - a place where friendly bystanders can lurk and follow our work:
>FOSS developers, users, etc.
>
>  - a little bit of the efforts we've put into dismantling the
>long-standing myth that Tails is produced by some sort of secret,
>unapproachable group of anonymous people
>
>  - a place where existing contributors who don't have access to our private
>communication channels can get a feeling of belonging, by hanging
>out with the rest of us
>
>  - a place where we can meet new contributors, get to know each other,
>collaborate and build trust until the project is comfortable with
>giving them more privileges
>
> Practically speaking, my main concern is that the implied subtle
> cultural shift and newly closed doors would make the boundary between
> in-group folks and kind-of-outsiders even harder to cross.
>
> This would make it a bit harder to go from "volunteer contributor" to
> "paid worker" (such transitions are rare in our recent past, but there
> are a few noticeable ones if we look further back in time), or from
> "unprivileged contributor" to "full-blown project member".
>
> Finally, note that we already lost quite some of this when we moved
> from IRC @ OFTC (where lots of FOSS contributors hang out already) to
> XMPP (which for many people would require extra setup work). IMO the
> status quo, in all these respects, is not great.


FWIW, as a former/lapsed volunteer developer (and still active FOSS
developer), I appreciated having a public chat that I could drop in to
ask questions of the devs.

I would've greatly preferred an IRC option, since I more generally use
that. I only set up XMPP to chat with tails developers when I needed
it, but it was useful when I did use it.

If possible, I'd love to see a public chat option preserved for
precisely the reasons intrigeri mentioned.

In any event, keep up the great work! Hopefully I'll find some time to
contribute again this year :).
--
-Austin
GPG: 267B CC1F 053F 0749 (expires 2021/02/18)
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Rewrite live-persist as part of Persistent Storage settings rewrite

[segfault]

Hey,

as part of the rewrite of the Persistent Storage settings (#17803), I 
also want to solve #11529 "Save data to Persistence when it is created 
(no need to restart)".
The only way I see to solve this while providing a nice UX is to rewrite 
part of live-persist (and the live-boot functions uses by it) to allow
activating/deactivating a single persistence feature (that's the term we 
want to use instead of "persistence preset" IIUC).


This is the user flow I envision:
* In the Persistent Storage settings GUI, the user clicks on the switch
  of a  persistence feature to  activate/deactivate it.
* The frontend calls the Activate()/Deactivate() method of the feature's
  D-Bus object.
* The backend checks if any processes are running that must not be
  running when changing this feature (for example for the Thunderbird
  persistence feature, no process with executable "/usr/bin/thunderbird"
  or "/usr/lib/thunderbird/thunderbird" must be running).
  * If any such process is running, the backend sends a signal that it's
waiting for these processes to exit.
  * The frontend receives the signal and displays a message to the user
that they have to close the corresponding app ("Thunderbird") to
continue.
  * Once all conflicting processes have exited, the backend
automatically continues activating/deactivating the feature.
* The backend mounts/unmounts the files/directories of that feature.
* The backend adds/removes the corresponding line(s) to/from
  persistence.conf.

live-persist is not able to mount/unmount a a single file/directory 
instead of the whole persistence.conf. That's why we need to rewrite 
part of it.


I plan to do that in bash, copying the parts from live-persist and 
live-boot which we need for that.


During boot, we could still use live-persist, or we completely replace 
it with the new script (which means that it should also be able to 
activate features from a config file).


What do you think about that plan?

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.