[Freedombox-discuss] my summary of yesterday's Hackfest

Wed Mar 2 11:01:16 UTC 2011

On Wed, Mar 02, 2011 at 08:10:57AM +0000, Matt Willsher wrote:
>On 1 March 2011 22:33, Jonas Smedegaard <dr at jones.dk> wrote:
>
>> On Tue, Mar 01, 2011 at 08:04:02PM +0000, Matt Willsher wrote:
>>
>
>
>> Let's not waste efforts running behind gmail, but leave it be and 
>> concentrate on what it is we have to sell: freedoms!
>
>
>I see your point and I don't dispute it's validity. In most ways it's 
>an easy goal for us then a bridge device.
>I particularly like your example there regarding WebIDs and FOAF.

Thanks.

>Is it a viable business model? That will sell enough units to build a 
>momentum? I'm not even going to concern myself with that one.

Me neither - I have opinions (which lead me to this lengthy 
conversation) but consider myself a lousy businessman.

>Ultimately I'm more interested in the under laying infrastructure than 
>the applications that sit on top of it.

Heh.  I guess most if not all of us wish we could just concentrate on 
parts of the puzzle.

Problem there is, that even leaving this whole discussion of what kind 
of services to offer, there is still a big difference in what underlying 
infrastructure is needed for e.g. a write-from-scratch Node- or 
CoffeeScript-based set of web apps and e.g. bulky-but-existing-today 
apps that are integrated tightly only at the backend (e.g. all using 
POSIX passwd and groups instead of own databases).

But waiting for the designers, who wait for the coders, who wait for the 
designers, won't get us far.

I have some experience in setting up some old-style "bulky" services, 
and intend to work in that direction for now.  Others are welcome to 
either join me, reuse parts of the tools and infrastructure I try put 
together but go in other directions, or work completely in parallel.

I do not see it as waste of time to do multiple things in parallel.

>>>> Actually, of your examples mentioned above, the Debian packaging of 
>>>> sudo now (since Squeeze) offers a config.d mechanism that other 
>>>> packages can hook into, and packaging of apache has for some time 
>>>> offered a (better!) combination of config.d and 
>>>> symlink-enable-disable script.
>>>>
>>>
>>> But something still needs to managed though linked files.
>>
>> What? Why?  Try provide an example.
>
>
>I have 5 users in my household. I have 1 admin, 2 power users and 3 
>users. Those groups each have different privileges mapped out in sudo. 
>The power users are allowed to restart apache and kick off backup. The 
>admin can become ultimate root. All valid users can map to one central 
>user to manage a bittorrent server.

Ok, so in your household you are sysadmin.

Now, imagine a project, different from the headless FreedomBox, aiming 
to provide a single machine with 8 heads (yes, they actually do that in 
some schools in Brazil!).  Let's call it FreedomBunker.

So the challenge is to have Debian install an almost completely standard 
configured system with GNOME and lots of apps - just with this tiny but 
(according to you) challenging adjustment of a custom sudo setup. Oh, 
and then the actual selling point of having it work with some custom 
hardware with 8 graphics cards, mice and keyboards.

Here's how I as a FreedomBunker fighter would approach that:

  1) Install a standard Debian setup on a standard computer.
  2) Customize by hand, following the howto on multihead while adding
     more hardware, and applying your current custom sudoers file and 
     users.
     NB! I create backups of any files that I mess with below /etc.
  3) Install another standard Debian setup on a standard computer.
  4) Try automate applying that same customizations you did at 2) and
     verify that intended improvements still work.
     NB! I try simplify as much as possible the config changes applied.
  5) Try re-express the simplest-possible config changes as either
     a) answers to package install questions (a.k.a. debconf), or b) 
     separate files in config.d style folders.  For sudo it just so 
     happens that since Squeeze the sudo package provides sudoers.d
     for this very purpose.  Also try express the changes generically,
     e.g. instead of hardcoding the account names in sudoers snippets, 
     use groups and add those groups with the specific accounts as 
     members.
  6) If I hit a wall (you won't with sudo and quite likely not with
     modern packaging of xorg either) of not being able to use either
     debconf or snippets, I work with the package maintainers to
     make it more flexible - starting with me filing a wishlist 
     bugreport against the package.
     NB! The world doesn't stop here until the package maintainer
     follow my wish.  I temporarily create a custom package which
     works as intended, but I really really do not want to have to
     maintain that fork for eternity so do not brag about it.
  7) I create a package containing the config.d snippets, and work
     with Debian to get this new package adopted officially.
  8) I create (e.g. using live-build) an install media using a)
     Debian packages, b) temporary local packages not yet adopted
     into Debian officially, and c) a list of debconf values
     injected at build time (a.k.a. debconf preseeding).
  9) I work with Debian to get also the debconf values adopted into
     Debian-installer officially.

Et voilá - the result is a Debian Pure Blend - a mixture (blend) of 
Debian consisting only (Pure) of Debian itself.

>> Debian mindset is to provide a fully working system consumable by 
>> "users" (both derivatives, sysadmins and end-users), not just a pile 
>> of fully working _pieces_ for sysadmins to tie together.
>
>
>The mind set to me as an outsider has always seem to be to provide a 
>basic set of choices to get a basic system up and running. After than 
>it up the the admin to get on with the tuning and customisation.  I 
>really don't want Debian making decisions for me.
>
> At this point I think I can safely say that we'll have to agree to 
>disagree on the principles of configuration management, but I would be 
>interested in reading more about the Debian projects agreed plans for 
>configuration management.

Debian is anarchistic.  You will find multiple answers to questions you 
raise.  And multiple answers can be correct: Debian has room for 
multiple ways to work concurrently.

Debian Policy is a document evolving over time, documenting borad 
consensus on technical matters.  Important point here is that it 
reflects actual _practice_ of the project, not theory that we wish 
should become practice - again we work anarchistic so change comes 
through actions more than decision on principles.

Debian Policy §10.7.3 contains:

> The scripts [which are embedded into a package and invoked during 
> install and removal] are not required to configure every possible 
> option for the package, but only those necessary to get the package 
> running on a given system.  Ideally the sysadmin should not have to do 
> any configuration other than that done (semi-)automatically by the 
> `postinst' script.

Hope that helps.

And hope you will change your mind and work _with_ Debian also on this 
front, rather than "hacking on top"!

  - 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/20110302/a6cb455e/attachment.pgp>