OT: general thoughts

[Chris Pressey <cpressey@xxxxxxxxxxxxx>]

Hi there.

Sorry if this is off-topic for this list, but there seems to be no
dragonflybsd-questions or -chat or -general or -advocacy or -philosophy
or -rants or whatever where this might be appropriate, as of yet.

I'm not a kernel hacker, but I really like the ideas & goals behind
DragonflyBSD, insofar as I understand them.  They remind me of one of my
favourite programming languages, Erlang (http://www.erlang.org/):

- lightweight processes(/threads/units of concurrency/whatever)
- preferred (/only?) IPC method is asynchronous message passing
- preferred method for passing parameters is through tagged lists

In Erlang these are as much for conceptual clarity as efficiency, as it
allows the programmer to model a problem using one process per truly
concurrent activity, while avoiding the complexities of shared memory
(and when you do need shared memory you can simulate it with a process.)

I guess my thought is that, although DragonflyBSD's goals are ostensibly
geared towards efficient implementation on, say, SMP systems(?), they
lend themselves to conceptual clarity and maintainability as well.  As a
(applications) programmer, I can deeply appreciate that.

As for packages: having ls and cp as seperate packages does sound a
little extreme on first blush, but it does make a lot of sense.  The
'base system' package would be no more than a dependency on the set of
(sub)packages that are required to build/install the base system.  It
sounds sophisticated, but really, it's not much more than plain ol'
'make'.  With sufficient package metadata - and it does sound like
Dragonfly won't skimp on the metadata, what with virtual package
environments and all - upgrading should be painless indeed.  Things like
stale libraries could be found out by keeping 'reference counts' on
installed .so's or whatnot.

While I'm on the subject of 'make' and upgrading - I'd be really curious
as to what people here think of the following (esp. as it relates to
Dragonfly, of course):

  http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html

Thanks for your time, sorry for the disturbance, probably won't bother
you again for a good long while as kernel hacking is way beyond my fu so
there's not much I'll be able to contribute for a while (besides maybe
documentation/philosophy/advocacy?)

-Chris