DragonFly users List (threaded) for 2004-12
Weapon of Mass Deduction <blacklist@xxxxxxxxxxx> wrote:
> Still, in practise, the current situation might be a good idea.
> The DragonFly-project is an organisation by and for people.
> Users, technicians, etc. It might be somewhat better for all
> parties involved to have a clear distinction between these
> certain parties.
> Suppose some kernel-developers have a bit of an
> argument with some userland-developers. If all these
> people/parties are involved in the same kludgy
> organisation, small differences in opinion can cause
Where there are people, there's frustration. All projects have it, no
matter what. It's more likely signal-to-noise issues that turn the
skilled developers away from end-user dominated forums. Which is
understandable. At the same time I think it would be bad to separate
kernel/system/app developers from each other or from end users. We're
all dependant on each other.
In the end it's all about people and communcation. Bad organization can
be worked around. Users have to make an effort to "read up" before they
go bug developers in a shared communcations channel. (Mailinglist/IRC
channel FAQs are good. They help make the informal "house rules"
visible so as to ease the friction...) Likewise, developers have to
make an effort on their end. Most consumers are not used to having to
respect the source of the solution, which may be a problem for some
developers. (Our unpaid open-source heroes.)
> But with the current concept, the GoBSD-organisation
> can clearly express its own point of view.
I think it would be bad to [completely] delegate such an important
thing as listening to the users and external developers. Having said
that I do think GoBSD can serve a good purpose as an end-user
> To put it simply, in technician-language: this will prevent forks.
I think the risk of forking has more to do with the people involved and
efforts made to keep communications channels open, and less to do with
how workload is split across groups of people. (well, I could be all
It's interesting though. IIRC, someone wondered if GoBSD was a fork,
and you say it'll prevent a fork. :))
> Also, consider the following. Is it not a good idea to let GoBSD
> contribute those tools, frontends, etc.?
Yeah, sure. Any development is good. While I'd rather replace a bad
back-end than patch it with nicer front-end, it is a temporary measure,
and could be seen as constructive criticism. Sometimes however it
really is best to not add a front-end, since that merely consolidates
the flawed back-end, making it harder to replace later on.
> Including independents
> who contribute through the GoBSD-channel, of course.
> Not that it think we should limit contribution of this kind to
> this, but why not let it be the standard procedure?
Limiting users and unproven developers to contributing only through
GoBSD?.. I wouldn't want that. Plus, we hardly know what GoBSD will
> You are totally right about the X-configuration. But harddisk
> partitioning is also needed for Windows installs... And simple users
> shoulnd't perform installs on their own. Mind: *simple* users.
Simple users should only use one OS, for simplicity, so they'd only
need one partition option: "Use all disk".. Or just a big button that
> And I don't think Linux is really that user-friendly...
Me neither, but they do have more friendly installers and partitioning
tools, and you're often booted all the way to a proper X login. (which
is the entry-level expectation of most people)
> Why? Manpages and commands are still very technical.
While they are an excellent source of much systemlevel information, the
system should be built so as to let most people avoid having to read a
man page, ever. IMO.
> > GoBSD could be the first line of defense, to allow the core devs
> > peace
> > of mind. It might also grow into a real commercial distro maker
> > offering the support most ordinary people expect and need. This is
> > no
> > easy task though.
> Well, your first line presents the current concept actually. The last
> two lines are susceptible to fierce resistance... And I don't think
> it is the right time to discuss that extensively. :D
> But let it be clear I'm also no supporter of that. If it is even
> possible with the current licensing scheme.
Sure it is possible. Anyone can fork the code any day, or simply
repackage it á la MacOS X, with some closed source solutions hooked
into it. They could charge as much as they like too, unlike with GPLd
stuff, where you can only charge for distribution costs + your "value
Anyway, if GoBSD can pull off a positive DragonFly distro, which is not
a fork but more of a polish job, sure, why not.
"Real people" would expect a whole lot more (in terms of support and
polish) from BSD than what I think (or speculate) the current BSD
projects are willing to commit to. If a commercial distro can provide
that, it might work.
> > Linux distro makers have started caring for real people and their
> > usability efforts are snowballing. Can it happen with BSD? I hope
> > so.
> How are they doing? By committing incompatible patches and
> custom tools and systems. So my point of view is that we should make
> things more clear and logical(!), instead of (only) simpler.
Yes, this is why I hope DragonFly itself could be the one and only
distro, but there will be organizational "growing pains".
Anyhow, I hope not all of this is bikeshed material. :]
/Jonas Sundström. www.kirilla.com