DragonFly BSD
DragonFly kernel List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: code bounties for DragonFly ?


From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sat, 28 Jan 2006 11:10:09 +0800

<200601271906.k0RJ6ClN097435@xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200601271906.k0RJ6ClN097435@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <43dae082$0$743$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 69.170.39.40
X-Trace: 1138417794 crater_reader.dragonflybsd.org 743 69.170.39.40
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:9548

Matthew Dillon wrote:

> :
> :Matthew Dillon wrote:

*trim*

>     ...  If all we did was push towards clustered
>     computing, everything else that makes an operating system useful
>     would become stale.  Say, oh, like applications!   Then we'd have
>     a clustered OS with no apps!
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

No, not even for one New-York minute....

Deliver a solid clustered OS that doesn't break, or even,
as an earlier step, a non-clustered one with less BGL hassle
| better FS choices | better inter-process communication |
  some other measurable advantage over *BSD | Linux
and apps will be adapted, ported, kludged, any/all of the above,
. ... faster that ants find sugar.

Might not be so if it DragonFly were some arcane QNX or
VRTX variant, but it isn't.

DragonFly still has enough UNIX / *BSD compatibility and
toolsets to make porting apps not only practical, but reasonably
fast for other coders who presently remain in 'wait and see' mode.

So long as the core remains *such* a rapidly moving target, OTOH, a
great deal of the app porting and packaging has to be done over,
and over, and over again.... Never-ending saga at the best of
times, worse to try and keep up with incremental changes.

Folks who do this difficult job are appreciated - greatly so!
But it is like mowing the lawn.  Damned grass just won't *stay cut*!

Their job might actually be easier if the kernel and core could be
skipped ahead in larger 'jumps' without the distraction of 'compatibility'
at so many intervening mileposts - which are known to be up for change,
and almost 'immediately' so.....

I'd like to see kernel and core coders concentrate exclusively on
what no one else can or will do...  Application-land will catch up when
the core starts stirring up bigger waves....

What kind of waves?  File system performance. Networking performance.
Data recoverability.  Ability to mount and use fs that *BSD cannot.

Bill Hacker







[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]