[Oberon] filesystem with directories ?
knapjack at gmail.com
Tue May 2 01:48:37 CEST 2006
On 5/1/06, Brantley Coile <brantley at coraid.com> wrote:
> > JMPO, but Plan9's concept & storage methodology done in Oberon
> > instead of 'C' would be 'of interest'.
> I agree. Are there any other readers of this list that have
> followed Plan 9?
I've noticed your crossover on at least the Inferno and I think the
Plan 9 lists.
I haven't thought this through completely, but my gut feeling is that
using directories facilitates code reuse, and I don't know how you
might implement the concept behind union directories without
In Inferno, Plan 9, and Unix in general, the whole idea that a file
(or directory) can be something other than a random-ordered
collections of blocks is the part that makes it powerful, not
necessarily the hierarchical presentation. They've just been
intertwined so long it's hard to divorce the two.
But, in terms of keeping things simple, the usage in Plan 9 and
Inferno are an interesting contrast to using something like XML config
The following disables hardware acceleration.
echo hwaccel off > /dev/vgactl
% cat /dev/sdD0/ctl
inquiry KENWOOD CD–ROM UCR–421 208E10/20/99 7.39 2 M0
config 85C0 capabilities 0F00 dma 00550004 dmactl 00000000
geometry 242725 2352
part data 0 242725
Having said that, I think things like Oberon's partition tools are
interesting in that you can feed the output back in, and it's well
integrated into the system and tool usage. Where Unix and progeny
have a similar give-and-take is the command line, and Oberon doesn't
currently have something akin to a shell where the interaction
is...different. I may not have words to describe where I'm headed.
Oberon is always a conversation. I convince you to do these things
and you oblige. Where I find myself fumbling with Oberon is when I
need something more terse: show me all the IP addresses in this file.
That's a different interaction, and I think calling it a command is
accurate. Do this. OK. Do this to this. Done. The interaction
(not necessarily the programming) tends to be staccato.
At its core, I think this staccato interaction has to do with the tie
to files. Not that it's a bad thing. Oberon has never seemed to be
tied to its files. It lives somewhere in between Unix and Smalltalk,
and in this moment I don't know how I might bridge that gap.
More information about the Oberon