[Freedombox-discuss] don't write code - user-friendly configuration
- Subject: [Freedombox-discuss] don't write code - user-friendly configuration
- From: firstname.lastname@example.org (Jonas Smedegaard)
- Date: Sun, 5 Sep 2010 19:01:46 +0200
- Message-id: <[🔎] 20100905170146.GP9279@jones.dk>
- In-reply-to: <[🔎] 20100905135925.GP16143@matthew.ath.cx>
- References: <AANLkTinMqo13eOZA+SCuVLuEkxgovX0egOKVu9kaXhhR@mail.gmail.com> <20100830091544.GB5282@jones.dk> <AANLkTikK9OpGPzSwhsU5JJiShhQmANiQCqJs+x065Hc0@mail.gmail.com> <20100830100427.GG5282@jones.dk> <AANLkTi=3_qtco2ghMBvxrorBXrx=HafCLWkUooHHO4_j@mail.gmail.com> <20100830114308.GK5282@jones.dk> <AANLkTimiAYomQZJtgFz0SqGb2PE0c+zaLK=1Kb4Fna1V@mail.gmail.com> <20100831095554.GP5282@jones.dk> <[🔎] 20100905135925.GP16143@matthew.ath.cx>
On Sun, Sep 05, 2010 at 02:59:25PM +0100, Matthew Johnson wrote:
>On Tue Aug 31 11:55, Jonas Smedegaard 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.
>> 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.
>One of the things I feel quite strongly about is that this device
>should be a turnkey, off the shelf device. With that in mind, we need
>to do everything possible to not ask users questions and where we must
>ask them questions, don't ask them questions they can't understand.
>In this vein I don't think that exposing debconf questions is going to
>work - they will fail one or both of the above criteria.
[nice details from user POV snipped]
>The key point to illustrate here is that you're not answering
>package-specific configuration questions, you're answering some general
>questions - which people will know the answers to - and the FB will
>configure all the software based on those. There should be modes to say
>"just work and don't ask me questions", which give you good defaults
>and there should be more detailed questions you can answer, but they
>should not be the sort of questions that debconf will ask.
I wholeheartedly agree. And don't see this point as colliding with mine
regarding relying on and strengthening debconf:
* You talk about FB users configuring their instance of FB.
* I talk about FB configuring its instance of Debian.
Those two overlap to wome extend, but let's start with the parts not
overlapping: Let's first look at settings equal for all FB instances but
not equal to a default installation of Debian...
We can choose to not treat the underlying components of FB as individual
upgradeable parts, instead using a snapshot of a complete Debian install
as atomic unit in the context of FB.
We then need to create and release a new snapshot each time Debian
release a security update to a Debian package contained in our Blend.
This will be our maintainance burden, as we chose to use Debian only for
installation, not for maintainance.
Knoppix is an old famous example of this, and many many tools exist to
do this kind of thing on top of Debian.
We can instead use some overlay mechanism to distinguish core snapshot
from changes on top of it, and permit Debian packages to upgrade
themselves and overlay with our customizations without the packages
knowing about those changes. This layering will be unique to our use of
Debian, and we therefore need to maintain that ourselves.
A branch of Skolelinux in Rheinland.Pfalz, Germany, tried using this
approach for a couple of years, using live-backup to handle the layers.
I am sure there are more tools than that around to do layering on top of
My preaching is to work *with* Debian instead of *on* *top* *of* Debian.
And my belif - argued in more detail in other posts of this thread - is
that the only sane approach is to use debconf, and enhance debconf.
We can discuss separately how to deal with things configurable by FB
users too, and how to have those interact with underlying packaging (or
not, if we snapshot Debian and reinvent the wheel of configuration
maintainance). But let's postpone that until clarified how to deal with
above simpler parts first.
(and yes, I started the confusion by talking about web UI for debconf,
it is clearly more complicated than that).
I want FreedomBox to live forever, and I believe the best way to ensure
that is to _not_ create a new _development_ community around it but only
a _servicing_ community, telling the existing Debian _development
community the needs of this particular kind of computing device.
* 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