[Freedombox-discuss] don't write code - user-friendly configuration
dr at jones.dk
Tue Aug 31 09:55:54 UTC 2010
Please consider writing cronologically (and snip the quoted parts which
you do not reply to). That eases readability of the correspondance.
Nore info at http://en.wikipedia.org/wiki/TOFU .
(my response is below the quote)
On Mon, Aug 30, 2010 at 07:38:45PM -0400, Chris Wj wrote:
>About that don't write any code thing... what about that creative easy
>to use web app that is supposed to be the way users set up their
>freedom box? That app seemingly will be coupled with the tools that run
>on the box.
>>>> On Mon, Aug 30, 2010 at 11:15 AM, Jonas Smedegaard <dr at jones.dk>
>>>>> As I see it, this FreedomBox project may not need to ever write a
>>>>> single piece of code!
I am very glad that you ask. This particular area especially have been
on my mind since a few years, and articulated during Debconf 10 to a few
peer Debian developers...
Let's see: an interface - likely web-based - to configure the box, and
probably do a bit of branding too.
That could be a unique project targeted specifically the FreedomBox, or
it could be hooking into existing tools already in Debian and itself be
reusable for other types of Debian installations too.
Writing specifically for FreedomBox is maybe simpler to grasp and faster
to implement, but limited-scope tools may also loose interest and
There is already one more general-purpose tool with a developer
interested in improving it to serve FreedomBox: Ægir. Let's help get
that tool packaged for Debian, let's help play with it and document our
needs of that tool for it to most ideally serve FreedomBox needs, and
let's help implement such improvements.
Let's also consider alternatives. Compare them, documenting strengths
and weaknesses, and perhaps keep open about multiple possible interfaces
- not just multiple stylistic "skins" but independent technical
approaches approach to user-friendly maintainance of a Debian system
each offered as a Debian package.
One alternative that I personally favor is to extend the de facto
standard package configuration interface in Debian, debconf, to be a)
more expressive and b) have a web frontend. And to help encourage more
debconf'ization of packages in Debian.
Debconf is the de facto standard interface for Package configuration in
Debian. It comes with a Perl library interface and a command-line
interactive UI, and allows "preseeding" answers to override defaults and
suppress them from being asked interactively. Debconf has some
limitations, however, when it comes to _maintaining_ packages - i.e.
dealing with package upgrades involving changes to its configuration.
These limitations do not show in normal Debian use, where the same
person, the sysadmin, both install the system and handle later upgrades.
When preseeding and passing on to another sysadmin - as Debian Edu does
and we will do with the FreedomBox, problems arise, however, as the
sysadmin will be asked questions about conflicts unknown to him: "Config
foo was changed locally - do you want to preserve local changes or
replace with newer packaging config?" is a common debconf question, but
catastrophic for the user experience if the changes "locally" from a
Debian package point of view is "upstream" from the sysadmin point of
view, due to the deviation from Debian defaults occured by others than
the current sysadmin (e.g. during custom FreedomBox install routines).
I have fought this issue in Debian Edu for some years. The classic
approach (which I suspect Ægir will use) is to work on the installed
Debian as a sysadmin - i.e. edit all config files at will: This will
break whenever the underlying package is upgraded to a version
containing a slightly different default config - such breakage can be
suppressed by simply ignoring packaged changes, and thus essentially
taking over parts of what is offered by Debian through its package
*maintainers*. A more modern approach is to overload packages with
conf.d snippets or rerouting to use completely different configuration
either located somewhere else of the filesystem or in a database: this
does not trigger debconf questions at package upgrade confusing the
sysadmin, but still loose the maintainance offered by the packaging.
The only proper way for a reliably maintained Debian->deployer->sysadmin
chain as I see it, is for debconf to be improved to handle reliably
other package maintainance tasks than install.
For a Blend like FreedomBox to reliably override defaults while still
tracking Debian package maintainance of same configuration, debconf
should distinguish between "I explicitly want what also happens to be
default currently" and "I don't care - use whatever is the default".
Package *reconfiguration* needs the ability to query current status. In
current debconf you can query the debconf _cache_ of earlier responses,
but cannot query the current choice as written to disk, so a user
interface cannot inform the sysadmin of the consequences of making a
choice - i.e. there is no "keep current choice" option.
A Debconf web UI would need to be quite more lightweight than a module
on top of the CMS Drupal on top of the scripting language PHP (as is the
case with Ægir, AIUI): it must require no daemons running to be usable
also in single-user mode, very few library dependencies to be useful as
debian-installer interface. Being lightweight is certainly a plus for an
embedded device like FreedomBox. I imagine it being a RESTful CGI
script, themeable to allow projects like this FreedomBox to add logo and
other stylistic spice without needing to invent and maintain a complete
tool on its own.
Beware, though, that Ægir is real - my scriblings above on debconf
improvements are only that: scriblings.
Sorry for this rather long post. I really should start blogging
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the Freedombox-discuss