[Freedombox-discuss] my summary of yesterday's Hackfest
On 2 March 2011 11:01, Jonas Smedegaard <dr at jones.dk> wrote:
> 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:
> 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.
Me too which I why I'm a salaried employee in an area not all that close to
my heart :(
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.
I am but how could this case possibly be configured by the Debian sudo
package? Or what if the roles of the people in the household change? Or what
if more people are needed or a new role?
> 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.
I believe this is a naive view of how systems work and if followed to its
ultimate conclusion removes freedoms and limits choice. I did find the
debconf overview page on the Debian site and it struck me as an incomplete.
I will read more on the subject as I think I believe in Debian's aims and I
think I would like to believe in its aims. I've drifted through
distributions long enough now to want to find one I can help.
> Hope that helps.
> And hope you will change your mind and work _with_ Debian also on this
> front, rather than "hacking on top"!
I prefer to view it as developing on top. Debian, RHEL, Solaris, AIX etc are
the important foundations. I just don't see how a software package can
become all things to all people with out additional glue.
-------------- next part --------------
An HTML attachment was scrubbed...