[Freedombox-discuss] my summary of yesterday's Hackfest
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.
>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
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
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
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
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 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