[Freedombox-discuss] don't write code - user-friendly configuration

Tue Aug 31 09:55:54 UTC 2010

Hi Chris,

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> 
>>>>  wrote:
>>>>>
>>>>> 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 
bit-rot faster.

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 
instead.

Kind regards,

  - Jonas

-- 
  * 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20100831/6734cf0d/attachment.pgp>