TBH, I skipped the functional/technical parts, but the ethics part, future goals and Q&A were clear and informative.
At Libreplanet, the ethics part is probably preaching to the choir, but you handled it nicely and clearly, in the context of the mobile phone ecosystem.
In the Q&A, a attendee raises the question of the included scripts, and your answer is that SXMO has to be more modular. It's clearly what I think every time I open sxmo_hook_contextmenu.sh (ugh!) or, to a lesser extent, sxmo_hook_inputhandler.sh. What's your vision on this? Mine is that the context menu should be splitted, one file per sub-menu or app. E.g. the package sxmo-ytdl would depend on youtube-dl and add sxmo UI stuff as contexmenu/inputhandler modules.
Thank you for the talk (and for SXMO, too :))
> TBH, I skipped the functional/technical parts, but the ethics part,
> future goals and Q&A were clear and informative.
> At Libreplanet, the ethics part is probably preaching to the choir,
> but you handled it nicely and clearly, in the context of the mobile
> phone ecosystem.
Thanks for watching! Glad there was something for you =).
> In the Q&A, a attendee raises the question of the included scripts, and your
> answer is that SXMO has to be more modular. It's clearly what I think every time
> I open sxmo_hook_contextmenu.sh (ugh!) or, to a lesser extent,
> sxmo_hook_inputhandler.sh. What's your vision on this? Mine is that the context
> menu should be splitted, one file per sub-menu or app. E.g. the package
> sxmo-ytdl would depend on youtube-dl and add sxmo UI stuff as
> contexmenu/inputhandler modules.
> Thank you for the talk (and for SXMO, too :))
The latest discussion about modularity is discussed here:
I will elaborate on why I think we need to pursue modularity in our
Right now, we've been putting everything into sxmo-utils and that
is not sustainable. Increasing scope is not necessarily bad - the fact
that people want to use our methodology (embracing Linux way of doing
things and making everything extensible) in developing mobile Linux is
really good. The goal is to make sure the increasing scope is managed well.
One of the ways to manage scope better is to make sure sxmo-utils is
only core functionality. Since we need to preserve git history for the
stuff that's already in sxmo-utils, we should add multiple make targets
for stuff that we want outside of sxmo-utils package. As that issue
suggests, someone needs to make a concrete plan for this such that the
maintainers can discuss since "core functionality" is a relative term.
Future code and past code written should be made modular. If users have an
issue with the language or library being used, they should be able to
program a replacement in their favorite language and have it mostly work
with Sxmo. Moreover, we should choose the right language for the job which
will be encouraged with a more modular ecosystem. For example, Im
currently looking into using superd which uses golang for supervising
our various daemons. The concurrency in golang is perfect for the
supervising daemon problem. Moreover, users on systemd distros will be
able to use systemd to monitor Sxmo services and other daemons.
I dont think superd can replace everything but it will make our system
more robust and modular overall.
Modularity should be pursued provided it's guided by the goals and end
benefits I explained here. I think your idea of splitting the packages
is nice. Perhaps context menus for a program should only be installed if
the user installs that program? postmarketOS does this for firewall
As you can see, you can setup apk rules to only install some files
provided a specific package is installed.
We also need to make sure the modularity doesnt make users think Sxmo
cant do X just because it's not in there by default. Users often
join irc asking for bluetooth support even though we have a package for
Im not sure the best way to advertise the more split packages and would
appreciate some suggestions =P. I hope that answered your question. Feel
free to ping me in irc if you need me to elaborate. Please discuss your
approach with a maintainer and get confirmation if it's a big change.