On 平成 20/08/29, at 19:23, macintoshzoom wrote:
Hi Owain Ainsworth,
Owain Ainsworth wrote:
On Thu, Aug 28, 2008 at 03:40:54PM -0600, macintoshzoom wrote:
Yes I have to do it, buy I'm a non-conformist,
I've found that 90% of the time when someone says that they actually
mean:
``I'm too stupid to know I'm doing it wrong''.
Yes, may be you are right and ``I'm too stupid to know I'm doing it
wrong''.
Since I'm something of an outsider here, myself, I'll translate that
for you.
BSD does things differently from Linux.
openBSD does things a bit differently from the other BSDs, kind of
like debian does things differently from Fedora. (But don't draw any
other parallels. Just understand that they're different.)
Even in the Linux world, what you're proposing is no small task.
Forking (and producing anything useful) is an even bigger task if
you have just started trying out a distribution.
(BTW, it could be argued that openBSD is _not_ a distro, not even a
distro of BSD.)
So, if you want to build wonderfully_easy_to_use_openBSD (cough), you
need to spend some time actually using openBSD, maybe even a lot of
time.
And you should probably understand one thing more. The guys who use
openBSD the most are the ones who do the dev work. Everything there
has a reason. It may not agree with your reasons and ideas, but,
especially if you are planning a fork, you should understand their
reasons and think carefully about your own before _you_ start
modifying _your_ _versions_ of the tools.
If your versions work for you, some of the guys here may be
interesting in looking at them, but there is no guarantee they'll
accept them for folding back into openBSD. Which is one of the
reasons you'll need a lot of disk space of your own, and a way to
keep track of the changes you make. (You think you're short of space
now?)
Many of us who use openBSD find it easier to own several machines
with different OSses and just use the closest fit for each job.
Which isn't to say you should forget entirely about your fork, just
that you need to move your personal deadlines back and schedule lots
more time for learning the tools and such.
Joel Rees
(who often finds himself needing to take the same advice)
