Hi,

Mon, Feb 05, 2007 at 05:20:10PM +1300, Shams wrote:

1. Does/will Hurd support something like built in version control of
files/directories (just like CVS) eg. achieval if one can install some
sort of fs filter driver, can this be done via translators?

Yes, this can be implemented with translators. AFAIK it hasn't been done
so far.

2. What about ACL at file or directory level? Now I believe auth
server will play some role in this? will a translator play a role
in this.

I guess you mean PSIX ACLs? These would have to be implemented in the
individual filesystems (ext2fs translator etc.), just like on any other
system. I don't think auth plays any role in this. (Not sure though)

Note that it's questionable whether PSIX ACLs are useful at all If
you need access permissions that can not be expressed using the ordinary
access bits (which are more powerful on the Hurd than on UNIX, because a
single process can have several UIDs), you are probably better off using
capabilities (Mach port rights in the current implementation) directly.

Unless of course you want to use some program that relies on PSIX ACLs,
and thus need compatibility

3. Now translators can they be developed so that they can be layered
on top of each other?
- an even higher level translator to print out the contents of xfiles
via http. - a translator sits here to control who can access this
directory for finer control /mnt/xfiles

Not sure what you mean exactly, but yes, translators can be layered. In
fact, every disk FS translator normally is layered on top of a store
translator.

4. Is it possible for translators to talk to each other or more
specifically is a translator just another server?

A translator is just a server attached to a filesystem node, and
usually, but not always, implementing an FS interface itself.

A translator can talk to other translators, just like any other programm
can.

BTW, this kind of questions would be more appropriate on
bug-hurd (AT) gnu (DOT) org .
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Sun, Feb 11, 2007 at 12:37:12AM +1300, Shams wrote:

Does/will Hurd support metadata capabilities or once again can/do
translators play a role in this? If translators were the case then how
could it achieve this (via extended attributes?).

No idea what you mean.

Could you please eloborate on ACL vs UID part a bit more.

Here is the scenario 1. UserA creates a file and wants to grant access
to lets say 5 groups via ACL (each group containing a certain number
of users) to a certain file.

Then how does UID solve this problem?

UIDs don't solve this problem.

The standard UNIX solution is very simple: Create a group with all users
allowed to access the file.

The presented scenario is extremely unlikely in practice, and in fact it
demonstrates a common misunderstanding of the UNIX group mechanism:
Groups do not represent any kind of "teams" or whatever; rather, groups
are tied to specific uses. If you want more abstract "teams", you need
an admin tool that manages them in an own database, and maps them to
UNIX groups as needed.

course, in UNIX, only the admin can create groups, which can be a
serious limitation in some situations. (Which is only very poorly solved
by PSIX ACLs IMH) The hurdish solution is to run an your own access
control mechanism, and do whatever you want. You could run your own
filesystem that uses different rules to decide who is allowed to access
the files. , probably more useful in most cases, you still store your
files on the system-provided FS, but you run a proxy FS server that
implements your own access scheme on top of it. This can be PSIX ACLs
if you really want them, but it can also be anything else you can think
of.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Sun, Feb 11, 2007 at 12:11:57PM +1300, Shams wrote:

Regarding metadata: I mean in the filesystem. Currently ext2 is used
as the default filesystem for Hurd. Now if you have a look at Reiser4
(or similar) then it has the possibility of assigning attributes (key
- value pairs) to a file or directory.

This is called "extended attributes" (xattr), and works for ext2 as well
AFAIK. (The Hurd implementation doesn't support it, though)

Linux for example has moved
>from ext2 as being the default fs a long time ago and now uses ext3
>as the
default filesystem.

Which, as you may know, is almost identical to ext2 but for the
journalling.

Also Reiser3 has been merged into the mainstream kernel too and I
think Reiser4 will be a likely candidate in the near future to be
merged into mainstream too.

Actually, it doesn't look that well for Reiser4. Reiser3 is practically
unmaintained, and will probably drop out of the standard kernel soon.
(SuSE, which was the only major distributor pushing it, already switched
to ext3.) The Linux developers for this and other reasons are thus very
scpetical about accepting any new Reiserfs version.

So what progress have or are we making to use something like ext3,
Reiser3, Reiser4 or XFS or similar in Hurd as the default filesystem?

Nobody is currently working on it. ext3/ext4 would be nice (though not
too high priority I'd say).

FSes are rather uninteresting -- too much trouble for the little
advantages they offer. And in the long run, we problably need a native
Hurd filesystem to make good use of hurdish features anyways
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

olafBuddenhagen (AT) gmx (DOT) net wrote:
And in the long run, we problably need a native
Hurd filesystem to make good use of hurdish features anyways

of curiosity, can you please mention what are the main hurdish
features that a native filesystem would put to use? Couldn't those
features be incorporated into one of the existing filesystem
translators?

Thanks,
Constantine

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Mon, Feb 12, 2007 at 08:23:57PM +0200, Constantine Kousoulos wrote:

of curiosity, can you please mention what are the main hurdish
features that a native filesystem would put to use? Couldn't those
features be incorporated into one of the existing filesystem
translators?

This is one of the (many) topics I want to write up something on, but so
far haven't managed

In short, the idea is that Hurd translators allow viewing structured
data as a directory tree, which is a very powerful concept IMH The
problem arises, if such trees are backed by actual disk files. Storing a
complex structure as individual files and directories is extremely
inefficient in a traditional filesystem, regarding both storage space
and processing time.

Alternatively, one could store the actual data in some serialized form,
like XML files. ( s-exps or whatever.) However, this is also extremely
inefficient and even fragile: If you change something in the tree
representation, e.g. replace a single entry by a larger one, the backing
text file will have to be rewritten completely starting with the
position at which the change happened.

course, with some special DB-like storage format, it's possible to
create more or less efficient data structures on top of normal files;
but this is rather complicated, fragile, and intransparent, and the
resulting structures can be processed only by using the DB translator --
unlike traditional directory structures or XML files, which can be
processed with standard tools. (Which is a problem especially when you
want to access the partition from another S, but limits flexibility in
the Hurd itself as well) Also, you get a disruption between the
normal directory structure, and the internal structure of the DB files
stored in it -- in some applications, it's rather arbitrary where to put
the division.

Ideally, there should be no division at all -- the FS should handle this
transparently, so complex data structures can be efficiently stored
"natively", and presented in either the expanded or the serialized form
as needed.

I don't think traditional disk filesystems can be used for that. It
requires a very different on-disk data layout.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Fri, Feb 16, 2007 at 07:55:33PM +1300, Shams wrote:

1. With ext2 for Hurd what is the minimum and maximum partition size
that Hurd can make use of or is restricted to?

If you use the Debian package, there is no special restriction. Note
however that the patch for supporting partitions 2 GiB is still not in
upstream CVS, in case you want to compile Hurd yourself.

Also note that for partitions < 512 MiB, you'll have to explicitely
force the block size to be 4096 Bytes. (For larger partitions, it's the
default setting.)

I mean for my Hurd installations is there a guide for
hardware/software requirements guide somewhere?

Not that I know of.

There are some know pitfalls though: No SATA; no shared IRQs for devices
that gnumach has drivers for (for unknown devices, it doesn't matter);
no IRQs above 15; and most AMD 64 bit machines do not seem to work,
though the reasons are not known. (No idea about Intel's variant.)

In general, Pentium3-class machines tend to work best; with anything
newer, you can easily run into trouble (gnumach mostly uses drivers
from Linux 2.0.)

2. In the MBR the partition type for ext2 is partition type 0x83, do
you know what this is for the Guid Partition Table (GPT)?

No idea.

Is the Hurd partitition types shared with the ones for Linux

Yes. Same filesystem, so same partition type. Note however that you need
to set the filesystem "owner" to "hurd".

and is this I think going to happen for some time to come?

No idea what you mean.

3. I assume that if I want to develop Mach/Hurd and related
translators etc, I will have to do this on Linux first and then create
an IS image to install into the required partition?

Why would you do that? The Hurd has been self-hosting for more than a
decade.

Just try installing the Debian GNU/Hurd distribution, see

4. Are you actively involved in developing for Hurd at the moment?

Strage to ask such a question on a mailing list -- who are you referring
to? Everyone here? Some specific person?

If you mean me: Well, marginally.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Sun, Feb 18, 2007 at 11:53:38PM +1300, Shams wrote:

I have got just one hard disk on my machine and its a SATA. So I
assume installing Hurd on it will be a problem for me?

Yes.

My cpu is also an Intel EMT64. So I assume installing Hurd on it will
be a problem for me?

Maybe. Would be nice to know, though -- I'm not sure anyone has tried
yet. You could test whether it boots with the live CD from

Would qemu solve these (above) problems for me?

Yes, that works. See

-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org