DragonFly users List (threaded) for 2004-12
Jonas Sundström wrote:
Weapon of Mass Deduction <blacklist@xxxxxxxxxxx> wrote:
To explain this more, I think DragonFlyBSD just isn't considered
'ready-to-use'. That's why GoBSD releases their own builds.
This way the DragonFlyBSD people are alleviated, as they do
not have to take (much) care of the problems of end-users.
I'm thinking any real effort to make the system better for everyone,
easier to setup/configure/admin has to be firmly based within the
DragonFly developer community. Any Desktop Environment (such as Gnome
or KDE) is limited* by the services provided by the base system. I
think much of the necessary work to make BSD more userfriendly is
spread across the base system and the ports** collection. (Everything
from argument switches, default modes, config file standards, and what
not.) Config scripts, tool frontends and GUI preferences can only do so
(* Take software rendered OpenGL. If the system doesn't offer 3D-
acceleration, the GUI layer can do software rendering, but it will
never be as good as accelerated 3D. Likewise, a D.E. can add filesystem
metadata via databases or whatever, but it'll never be as clean as a
real metadata filesystem, where the metadata stays with the fs
entities, no matter what.)
I get your point. I know my argument is a bit faltering due to it.
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.
It is hard to explain, but let's give a practical example of the impact
of your view.
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
But with the current concept, the GoBSD-organisation can clearly express
its own point of view.
If the DragonFly-organisation does not agree with the demands of GoBSD,
which would have a certain authority due to loyal support of the
DragonFly-BSD-userbase, this would result in a concensus.
Of course, it is theory, but I think the current concept remains
something which we should not blindly turn down.
To put it simply, in technician-language: this will prevent forks.
Also, consider the following. Is it not a good idea to let GoBSD
contribute those tools, frontends, etc.? 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?
DragonFly-base will still be improved accordingly, just like
you would like to see.
My point is: the (named) benefits of your concept can also be achievied
through the current concept. But let it be clear that I'm not fully
supporting any concept at the moment, because I want to be objective.
(** If X would auto-configure itself, we'd have lots more potential end
-users. Harddisk partitioning is another stumbling block. One could
argue that we don't want user who can't accomplish these tasks, but
that is rather limiting the growth potential of DragonFly, and possibly
the reason why Linux is so much more successful.)
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.
And I don't think Linux is really that user-friendly...
Why? Manpages and commands are still very technical. That's no problem,
as long as they are logical and understandable. Also, they are
incorporating many unnecessary jokes, that are fun for some, but not
professional or presenting a user-oriented image...
By example the "man sex" command, as it is one I happened to hear of.
What if a sexuology-researcher had some application which had the
name "sex"... That seems far-fetched, but for a professional OS, you
simply don't want those GNU-type jokes incorporated *by standard*.
In the future I will propose some documentation patches to take care of
that kind of issues, that's sure.
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.
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 introducing
custom tools and systems. So my point of view is that we should make
things more clear and logical(!), instead of (only) simpler.
BTW, it's ironic how the terms 'i18n' and 'l10n' are supposed to
the efforts to give computers more people skills.
/Jonas Sundström. www.kirilla.com
Hehe. Well, that's a bit unfair, localisation and that sort of
initiatives are not truly oriented towards users, more towards
developers which are concerned with users.
But your example illustrates mine, and reverse of course. ;)