* Lucio De Re wrote:
Hi,
> If the cloud were to be a mere repository of (encrypted) Venti blocks,
> wouldn't it be a very useful tool?
Actually, I already had been doing some works in that area.
Not actually venti, but a some bit similar object store,
which supports some kind of distribute gc,
My humble apologies for the multiple copies, my fingers slipped.
++L
--- Begin Message ---
> did i hear cloud-backed directory entries?
I'll bite:
If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?
In fact, how do we know that Al Qaeda are
> did i hear cloud-backed directory entries?
I'll bite:
If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?
In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganog
> did i hear cloud-backed directory entries?
I'll bite:
If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?
In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganog
> did i hear cloud-backed directory entries?
I'll bite:
If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?
In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganog
> did i hear cloud-backed directory entries?
I'll bite:
If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?
In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganog
> >> >> > > This feature might be more useful if the directory entries
> were > presented to clients of the FS in a textual format, but that
> would > encourage, if not require, far more parsing in the system, and
> that is > bad both for performance and for security.
>
> Sounds like a good argume
did i hear cloud-backed directory entries?
On Feb 3, 2011, at 9:30 PM, Robert Ransom wrote:
>>
>>
>
> This feature might be more useful if the directory entries were
> presented to clients of the FS in a textual format, but that would
> encourage, if not require, far more parsing in the system, and that is
> bad both for performance
On Thu, 3 Feb 2011 20:49:17 -0500
erik quanstrom wrote:
> > FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> > expect the other free BSDs to have that misfeature, too.
>
> i don't see how allowing this is a misfeature. regardless,
> plan 9 allows it.
>
> ; sha1sum < /adm/tim
> FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> expect the other free BSDs to have that misfeature, too.
i don't see how allowing this is a misfeature. regardless,
plan 9 allows it.
; sha1sum < /adm/timezone
05d16cd216a58fae746ae36f72c784d10bcc1392
- erik
On Thu, 03 Feb 2011 18:42:39 +
smi...@zenzebra.mv.com wrote:
> There's no way that I know of to possibly interperet a path ending in
> "/" as a file (with the exception of reading raw Dir data, as on Plan
> 9 or "cat /" on, what was it, Solaris?).
FreeBSD 8.0 lets you cat the raw data of a di
> me wonders what ever happened to Hans...
Is that really necessary? I'm guessing it was intended as a joke.
Back in the 10th grade I spent a few months running a Reiser4 linux
root. It was kind of a piece of junk, frequently locking up and
giving inconsistent performance. C.f.
http://en.wikip
try asking his jail warden.
On Thu, Feb 3, 2011 at 4:24 PM, wrote:
> /me wonders what ever happened to Hans...
Eric Van Hensbergen writes:
>> build an experimental OS around it! But if you go this path,
>> do consider providing a few more datatypes in the filesystem
>> (integers, file-id, strings, ...). Basically persistent data
>> types. Or just use an object or relational database as your
>> filesystem
On Thu, Feb 3, 2011 at 10:58 AM, Bakul Shah wrote:
> On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries
> wrote:
>>
>> why do we keep distinction between files and directories?
>
> David Cheriton's `thoth' operating system didn't keep this
> distinction. But every other OS I know of keeps them
>
On Thursday 03 of February 2011 19:42:39 smi...@zenzebra.mv.com wrote:
> dexen deVries writes:
> >> oh yes, maintaining the usual semantics for cp becomes tricky.
> >>
> >> mkdir z
> >> cp x.c z
> >>
> >> do i mean to write x.c to z itself, or to a new file within z?
> >
> > nb., with the curre
dexen deVries writes:
>> oh yes, maintaining the usual semantics for cp becomes tricky.
>>
>> mkdir z
>> cp x.c z
>>
>> do i mean to write x.c to z itself, or to a new file within z?
>
> nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous
> you want to create a child
On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries
wrote:
>
> why do we keep distinction between files and directories?
David Cheriton's `thoth' operating system didn't keep this
distinction. But every other OS I know of keeps them
separate. IIRC thoth provided functions for getting the
first c
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in t
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in t
On 3 February 2011 13:44, dexen deVries wrote:
> On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
>> On 3 February 2011 11:45, dexen deVries wrote:
>> > read(open("/foo")) returns byte stream under entry `foo' in the root
>> > object.
>> >
>> > readdir("/foo") returns `bar' (and poss
> How about 8c(1)? would it be too confusing to issue:
> 8c foo.c
> if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C
> code?
>
> rc(1)? How could `. foo.rc' handle situation when also
> `foo.rc/bar.rc/baz.rc'
> exists?
exactly. this is the same problem one has with a
On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root
> > object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical section of
On Thursday, February 03, 2011 02:05:02 pm erik quanstrom wrote:
> > why do we keep distinction between files and directories? Does it provide
> > any extra value over model with unified file/directory?
>
> yes. the advantage is that it's easy to tell the difference
> between a file and a directo
On Thu Feb 3 08:39:20 EST 2011, rogpe...@gmail.com wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical
> > section of ob
On 3 February 2011 11:45, dexen deVries wrote:
> read(open("/foo")) returns byte stream under entry `foo' in the root object.
>
> readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
> section of object `/foo'.
there's no distinction between readdir and read in plan 9.
> why do we keep distinction between files and directories? Does it provide any
> extra value over model with unified file/directory?
yes. the advantage is that it's easy to tell the difference
between a file and a directory. and we have a lot of code
that works with the current model.
what is
As this list seems to be open to discussion of strange OS-related ideas, here
goes my question:
why do we keep distinction between files and directories? Does it provide any
extra value over model with unified file/directory?
A possible consideration for representation of unified files/director
29 matches
Mail list logo
