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

Wed Sep 1 22:07:31 UTC 2010

On Wed, Sep 01, 2010 at 06:59:41PM +0200, paxcoder wrote:
>On 09/01/2010 06:19 PM, Jonas Smedegaard wrote:
>>On Wed, Sep 01, 2010 at 04:47:51PM +0200, paxcoder wrote:
>>>That's a tough one. I think it'll take too way much time and 
>>>hassle for our config changes to reach FB users.
>>
>>Skolelinux instructs its users to reinstall to newer major releases 
>>rather than upgrading. I find that unacceptable for FreedomBox.
>
>I don't quote get your point here. Why would users need to reinstall 
>things in any scenario?

Skolelinux based on one stable Debian release cannot be reliably 
upgraded to the version based on next stable Debian release.

Skolelinux documentation[1] contains the following warning:

>Upgrading Debian from one distribution to the next is generally rather 
>easy. For Debian Edu this is unfortunatly not yet true as we heavily 
>modify configuration files in ways we shouldn't do. (See Debian bug 
>311188 for more information.) Upgrading is still possible but might
>requiere some work.

The "work" required is that some of the many questions silenced during 
initial install popping up with 3-way merge questions, and (worse!) 
packages silently stopping to work due to bypassing configuration in 
ways not detected by the packaging but still causing the underlying 
software to not work properly.

Both types of questions means upgrades are *not* automatic but needs 
interactions regarding technical details - a no-go for FreedomBox.

[1] http://wiki.debian.org/DebianEdu/Documentation/Lenny/Upgrades

>>I would prefer a very simple FreedomBox - e.g. providing only 
>>routing and a single web page with Web-ID and Webfinger - which was 
>>upgradeable, over one with e.g. filesharing and a CMS which could 
>>not reliably be fully automatically be upgraded to next major 
>>Debian release.
>
>Yes, but this is supposed to be a product for your Average Joe, with 
>a sleek and easy-to-use interface. The interface would be upgraded 
>for new versions of programs (or more frequently perhaps, backends to 
>these programs would be updated) just like it's the case with Webmin, 
>or phpmyadmin or any web or non-web based GUI front-end. Filesharing? 
>I pressume you mean as part of GNUnet - GNUnet would upgrade just 
>fine - like any other debian package. If you mean distributed storage 
>or some other "non-standard" thing we might come up with, we'll just 
>need to make a new packet for it. We should not chip away from the 
>project for convenience.

Not sure what your point is above.

Yes, I also want FreedomBox to be both reliable, full of features and 
dead simple to use.  All of that takes time and effort to do right, 
though, and I don't want to wait forever to launch it, so I talk about 
which parts I want _first_.  Which parts can be weak or missing in the 
first couple of years of FreedomBox.

Skolelinux have been in development for about 10 years now, all along as 
a close derivative of Debian.  Yes, each individual piece is smooth to 
upgrade - it is Debian. But anyway the grand result have so far been too 
complex to reliably upgrade - the official recommendation of a reliable 
upgrade is to backup all data, erase the harddrive and reinstall the 
newer release from scratch.  Even though it is closely based on Debian.  
Even though all binary parts *are* Debian - only configfiles have 
changed so in principle it shouldn't be hard - just a bunch of textual 
hacks which needs to be maintained.

>>Sure, adventurous users can always throw in testing, unstable or 
>>even experiemental additions, but I find it crucial that what we 
>>offer officially is as reliable as Debian itself, which to me means 
>>that it must *be* Debian itself.
>
>To be quite honest, stable is virtually pointless to me.

I did not talk about Debian branches/suites/whatever.  Please start a 
separate thread on that topic if you wish.

If those generic terms confuse you, then perhaps it makes better sense 
to use "reliable pieces", "maybe-reliable pieces", "unreliable pieces" 
and "odd pieces".

I assume we all aim for a FreedomBox based solely on "relieble pieces" 
while offering the freedom of our users to enhance/ruin their boxes by 
volunteerly adding less reliably or outright weird pieces as well.

>>>I also doubt maintainers would be willing to have alternative 
>>>configs in their packages that they'd need to maintain, basically 
>>>treating FB as an arch against which they would be required to 
>>>test on.
>>
>>Hey, you exagerate: FreedomBox is not an architecture but a Blend.
>
>A blend that I think will prove quite unlike the main distro. It's 
>meant for different things, and it does common things differently. 
>But I'm not a DD so I don't really know all that can and cannot be 
>done with Debian.

Debian is meant for all sorts of different things, including desktops, 
phones, autonomous robots and servers of all(!) sizes.

There is no "main" purpose of Debian.  Perhaps you confuse it with 
Ubuntu or some other (Debian-based?) distribution.  OR maybe I totally 
misunderstand what you are trying to say above...

What I try to say is that package developers need not treat FreedomBox 
any special, just as they need not treat Debian-edu a.k.a. Skolelinux, 
Debian EzGo, DebianMed etc. any special.  Package developers need to be 
concerned about the users of Debian, and some users of Debian are 
represented by Debian Pure Blends:

A Debian Pure Blend is "a subset of Debian that is configured to support 
a particular target group out-of-the-box."[1] I find that description 
more accurate for FreedomBox than an "architecture" - in fact we would 
benefit a lot from staying architecture-agnostic!

[2] http://wiki.debian.org/DebianPureBlends

>>If it does work but not configured how we need it, then we should 
>>not maintain local hacks to improve it, but help work with the 
>>package maintainer(s) in making the packaging more configurable.
>
>If we can still make a unified web gui to configure packages that way 
>instead (or automatize things), I'm up for it.

What I talked about so far was not the Web UI, but the underlying parts 
of dealing with a) choices in software and b) choices in packaging.

However we apply a UI on top, we need to decide on whether we want to 
obey the programmatic interfaces offered by the Debian packagings of 
bypass them and instead work directly with the underlying configfiles, 
config databases and whatever other config mechanisms available inside 
the pieces packaged.

Whether we want FreedomBox to benefit from Debian *maintainance* of 
package configurations, or think we are better at that than Debian!

>>If we pass on some GNU social configuration choices to our users 
>>and discover that the packaging only reliably supports install-time 
>>customizations, then we should not maintain local hacks to cover 
>>over that, but help work with the package maintainer(s) in e.g. 
>>using Config::Model to improve reliability in dealing with 
>>non-virgin configfiles.
>
>That's the part I didn't know. Any links about Config::Model?

http://wiki.debian.org/PackageConfigUpgrade

>>>So I'd talk about scenarios where we do write and maintain our 
>>>code for our specific needs.
>>
>>It is dead easy to start local hacks, and difficult to imagine how 
>>we will forget to properly maintain it.
>
>No, that's easy too. But I didn't know there were any other 
>workarounds until you told me. You'll have to teach me (and other 
>non-DD's) the tools to do this though.

I am happy to tell what I know.

The promising tools like Config::Model are no magic bullets, though: 
Those tools are new so not adopted by a lot of developers yet, and 
currently solve only parts of the puzzle - the rest needs to be 
"hand-held" by strong devotion to the principle of "all maintainance 
must be embedded in debian packges, not applied on top".

...or tell me if reliable upgradeability is not most important.  If we 
the first couple of years should just grow a pile of local config hacks 
applied sysadmin style using Ægir, Puppet, FAI, CFEngine or whatever, to 
quicker reach a FreedomBox loaded with all the great powerful features 
we want from it (even if our users then may need to reset their boxes 
once in a while when it "hangs" during some security upgrade).

>>So you agree that local hacks won't fly, or did I misunderstand and 
>>your point above is something else?
>
>I deprecate "local" modifications too. I'm still concerned with 
>viability of making the project subset of the official distro, but 
>for now, I'll take your word that it can be done. As long as it 
>doesn't limit us in what we're set to do, I'm perfectly happy. Or 
>more universally, I say obey the standards (de-facto or otherwise), 
>unless they conflict with freedom or progress.

"as long as it..."! He he, that was a good one.

No, you can't eat the cake and have it at the same time.  Reliable 
upgradeability will slow down speed of progress, and until reaching each 
success in working with package maintainers (which _will_ require 
patience) it will limit us.

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/20100902/55f3e2f3/attachment.pgp>