Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[olafBuddenhagen]

Hi,

It's a bit strange to answer here, as part of the discussion seems to
have gone on off-list. Yet there are a few things in your mail that even
lacking context I feel compelled to set straight...

On Mon, Dec 08, 2008 at 02:19:34PM +0100, Michal Suchanek wrote:
> 2008/12/8 Arne Babenhauserheide <arne_bab@web.de>:
> > Am Freitag 05 Dezember 2008 12:40:32 schrieb Michal Suchanek:

> Sure, and you might also want control its memory usage, and that it
> cannot access the memory of other processes (because it is no debugger
> it has no business doing so).

In the hierachical security model we proposed, a process is protected
from other processes, but *not* from it's parent. Whether the parent
actually wants to debug on not -- it always has the permission to do.
And we believe this ability to be fundamental for any system that
respects user freedom.

> And once you have access control that actually works you can turn it
> into DRM by giving up some rights so some system service that
> implements DRM.

Yes, as I explained in my last mail on that subject, it's technically
possible to run a service outside the user's control to implement DRM.
But -- as I also explained in that mail -- it requires explicit action;
more exactly, it requires the administrator actively taking part in the
treachery against the user.

This is very different from an EROS-like system, where any process
started by the user and running on the user's resources, can implement
effective DRM whenever it wishes to. The mechanisms for that are
provided by the system by default, and neither the user nor the
administrator can prevent it.

If you are not able to see the difference, I can't help you.

> Then you are out of luck actually. Because "secure enough to implement
> DRM" is less than "secure enough to prevent as many breakins as
> possible".

This is bullshit. Not every kind of security automatically enables
effective DRM. I already explained why, and I won't explain again.

> "Better than POSIX" is actually very low standard in my view.

This is easy to say, as we know the shortcomings of POSIX well.

Yet I bet that if you created a new set of APIs from scratch, you would
make just as many errors as the UNIX creators did -- only different
ones.

> > So we are now talking redesigning most applications.
> 
> Yes, most applications are unreliable, insecure, miss important
> functionality, and have poor UI.

Good luck reinventing the world.

I hope you understand that this is not what we are interested in.

> > But I know that just the changes Gentoo ebuilds make to get programs
> > running in the environment they are designed for can become quite
> > mmuch work, and I get the impression of quite much pain when I think
> > about porting nontrivial stuff to a pure capabilities system.
> 
> You experience pretty much the same pain porting stuff to the Hurd
> which takes POSIX to the letter and does not implement certain
> optional aids on which many POSIX programmers like to rely.

Sorry, this is just utter bullshit.

Presently nearly 60% of all Debian source packages (that is more than
4600 packages) build on the Hurd -- and most of them actually work.

The majority of these packages builds out of the box, without any
changes. (We sure did not fix 4600 packages by hand...) Some needed more
or less trivial patches (a few hundred perhaps), and a handful required
more serious porting.

(Of the remaining 40%, more than half are waiting on other packages they
depend on; less then 20% of packages actually failed building. If the
build dependencies were resolved, it is to expecty that again 60% of the
dependant packages would build fine. All in all, we can extrapolate to
about 25% of all packages failing on their own accord -- and again, most
of them probably require only trivial patches to fix.)

I want to see you pull this with a system that doesn't implement POSIX
natively...

-antrik-