Re: Part 2: System Structure

[Pierre THIERRY]

Scribit Bas Wijnen dies 15/05/2006 hora 10:00:
> Also, allowing the game to just disappear in the middle of a
> high-score update seems very bug-sensitive.

There is a design pattern that would avoid such bugs: the program on
user's resources calls a service to update the data, and such a service
should check if request was complete or not.

This kind of bug could only appear if the program updates the data
itself.

> The high-score data is information, owned by the competition, but you
> may use it a bit.  However, only according to the rules of the
> competition.  Sounds like DRM to me...

I may not use information for the high-score a bit. I may read it and
transfer it as I like, and I can only ask in a specific channel to add
something in it.

That sounds very different from DRM to me. Maybe I'm misunderstanding
what DRM is.

> > > plus opaque resource donation,
> > I don't know what you mean by this.
> Revocably donating a piece of storage that the donor cannot inspect or
> change himself.

OK. I don't see how to avoid it without a big overhead.

> Transparently giving away resources will definitely be possible
> (that's when the donor can revoke, inspect, and change it).  For CPU
> it doesn't matter.  There's nothing to inspect.  For storage there is
> a difference.

Then the only solution is that the user only provides CPU and the game
provides storage. But then sometimes the game won't be playable by
players because too many of them are already playing. That doesn't sound
like a good solution to me.

> > On my system, there are 79 of them just in /usr/games, for 472
> > packages in the game section of Debian etch.
> These are games that support a competition, I suppose.  In case we
> agree that for those we don't actually want them to run on the user's
> resources, I don't think there is a problem.

But we don't agree. ;-)

> > 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.
> Actually, ping may need to be a service.  The reason it is on Unix is
> that the user is not trusted with raw access to the network card.

Sure. For things like ping or traceroute, a Hurd-NG will be far more
simple and secure.

> "writing an utmp entry" could be a service provided by the system.  I
> don't think there should be any check that it is only called by a
> "real" terminal.

OK, so those are not a problem.

What if the administrator wants to enforce some policy about what can
update utmp, though? I think we fall back to the previous use case.

Quickly,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature