On Wed, Mar 02, 2011 at 08:10:57AM +0000, Matt Willsher wrote:
On 1 March 2011 22:33, Jonas Smedegaard <[email protected]> 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 addingmore 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
signature.asc
Description: Digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
