[Top][All Lists]

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

Re: Part 2: System Structure

From: Pierre THIERRY
Subject: Re: Part 2: System Structure
Date: Mon, 15 May 2006 03:12:22 +0200
User-agent: Mutt/1.5.11+cvs20060403

Scribit Marcus Brinkmann dies 15/05/2006 hora 02:07:
> This is just because you are trying to do something that is very
> complicated.

But I guess I won't be the only one. And I'm sure it won't be too hard
to find other use cases that match this one.

> On the one hand, you want to run the competition on the users
> resources, on the other hand, you want the competition to be able to
> reliably update the high score file.

I indeed want to program to run on user's resources, and I want that the
program I choose be the only way to have write access to some data.
That's the abstract scenario.

Program is game and data is high score in this competition example.

> In these requirements you are already presupposing DRM

No I ain't. Or I don't know I am.

> plus opaque resource donation,

I don't know what you mean by this. Someone answered me in private that
giving resources to a server for it to process a request was already
considered for Hurd-NG.

Do you mean giving CPU/storage to a server along with the request won't
be possible in Hurd-NG?

> plus a non-confined "competition constructor" server,

Something like that, I suppose. I didn't think much on the solution,
only on the problem. ;-)

> plus a careful competition program design that runs some parts of the
> competition on durable resources and some on non-durable resources

I'm not sure I presupposed anything like that, because I'm not sure I
understand what you mean. ;-)

> All of this is technically possible, but the complexity is inherent in
> the goal.

But maybe there are some goals that we should support that fit in this
use case. Just check every setuid/setgid executable in a system with a
fairly large number of packages installed and check how you would deal
with it...

On my system, there are 79 of them just in /usr/games, for 472 packages
in the game section of Debian etch.

If you intend to have Hurd-NG used on typical desktop systems with
typical people (that is, that might want reliable competition software
on their system), then you have a problem here, I think.

I also have 73 of them in {,/usr}/{s,}bin, though many of them are
either abusive use of setuid/setgid or unnecessary in Hurd-NG, like
mount or ping.

There are some terminal emulators in them, which maybe fit the use case:
they write utmp data. I don't know if it is of any importance for

> In Unix it just looks simpler because the resource accounting is
> sloppier.


Nowhere man
OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]