GoBSD.com

Weapon of Mass Deduction blacklist at internl.net
Sat Dec 11 16:07:26 PST 2004


Jonas Sundström wrote:
Weapon of Mass Deduction <blacklist at 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 
frustration.


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.)
Yes, but consider the metaphysical side of the coin...
Okay, I would find it nonsense myself really, but many people are 
affected by this.
Some people who post to these newsgroups/mailing-lists are said to
be too busy carping at FreeBSD...
So, with some bad experience in the past, people become frustrated.
This would result in many disliking the whole DragonFly-BSD-OS just
because a small disagreement about some high-level issue.

Well, you will ask now what better situation this separation of concerns 
would realize then...

I think people will be more satisfied knowing that GoBSD (or a generic 
organisation like that) is putting their complaints/experiences on the
agenda. If they would complain themselves, it possibly has far less 
chance of turning out as intended (because of failure of the end-user in 
question to make the developers understand what he/she means, etc.). 
Again I want to point out that it would alleviate the developers and 
other (core) project members, so they can focus on their primary tasks.

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 
communications channel.

 ...

I do not mean it should be completely delegated, see:

"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.".
So I agree with you, actually. :P

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 
wrong. ´:)
Hehe, in fact distribution of workload is not the main achievement.
This communication you are writing about, is exactly what is involved
in the frustation-argument I have written. :)
It's interesting though. IIRC, someone wondered if GoBSD was a fork, 
and you say it'll prevent a fork. :))
Well, if one does not understand things right, striking correlation with 
other messages is purely by chance. ;)

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.
I'm writing of frontends that stand on their own, just like any other
port/programme. So this also doesn't exclude improvements on the 
'back-end'. But you were the one that mentioned it first, remember. :P

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 
become yet.
As I wrote, I certainly also wouldn't want that. But if GoBSD will
remain a (free) project, I do not have any objection if it would be
decided that high-level contributions are handled by GoBSD standardly.
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 
says "Install".
Windows only has this option for (the highly-technical) unattended 
installs. But I remind FreeBSD (5) also has an option "Automatically
partition the [selected] disk.". So, though I never executed the 
installer of DragonFly-BSD, I expect it is avaible in that too.

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)
The X-installation should indeed be better as I already acknowledged. 
But though the installer might not look very modern, it is not more 
difficult to understand, right? Except maybe the keyboard-navigation.
But that can be handled by the ncurses-developers (isn't that the
tool used to visualise the installation?).

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.
Indeed. Take for example, the question how one can exit a man-screen.
'ESC'? 'CTRL'-'C'? 'CTRL'-'X'? 'ALT'-'X'?
None of those key-combinations work. It can be exited by pressing 'q'...
How is a new user supposed find this out???
It would require him/her to read the manpage presented by executing "man 
man" first...

That's just extremely elaborate and unnecessary.

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 
added" stuff.

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.
Yes, but the pain will be that GoBSD seems then to be arrived like a
vulture to 'exploit' this project. Because the issues it adresses could 
very well be adressed by the DragonFly-BSD-project itself, like you wrote.

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.


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
LOL, bikeshed material, that's some Swedish saying right? :D
I can't translate it, and it happens to be non-dutch also. :P




More information about the Users mailing list