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

[Michal Suchanek]

2008/12/18  <olafBuddenhagen@gmx.net>:
> Hi,
>
> On Mon, Dec 15, 2008 at 12:09:19PM +0100, Michal Suchanek wrote:
>> 2008/12/12  <olafBuddenhagen@gmx.net>:
>
>> I see that the EROS or Coyotos as a whole does not fit the
>> requirements of a GNU system but I think reusing some basic parts is
>> no worse than using any other kernel.
>
> Well, if we don't use the constructor mechanism, the persistence/storage
> mechanism, the resource management, nor the IPC: Which parts of Coyotos
> exactly would we use?...

I find persistence and storage mechanism that works well with it quite useful.
I also do not see why do you want to throw away secure IPC and
resource management which is exactly what was missing in L4.

>
> (Viengoos presently (mis)uses some parts of L4 as a hardware
> abstraction. This is about as much as it could use from Coyotos -- only
> that L4 is much better in this regard. It existed for years, and can be
> considered pretty mature by now. And it is more minimalistic, making it
> easier to use only the hardware abstraction, ignoring all the parts we
> don't need.)
>
>> DRM is just a security policy that can be built on top of any security
>> that is actually usable.
>
> Only if you assume that "security that is actually usable" implies
> hiding things from the parent process. As I already explained, we
> believe this assumption to be fundamentally wrong. Get over it.

As I said numerous times hiding things from child process can be
turned into hiding things from parent process. After all, your login
shell is normally started by some other service which has all the
power to hide things from it. The only difference we are discussing
round and round is whether this service is configured to possibly hide
something from all shells or if there is a 'root' shell that can
access everything.

>
>> > Presently nearly 60% of all Debian source packages (that is more
>> > than 4600 packages) build on the Hurd -- and most of them actually
>> > work.
> [...]
>> And how many of them use any Hurd specific features? If all you want
>> is the application compiling and running on the system then you can do
>> that on any system that provides POSIX compatibility in one way or
>> another.
>
> First of all, users can make use of Hurd features in many cases
> *without* applications using them explicitely -- in fact, most of the
> things mentioned in this thread (before you turned it into Hurd bashing)
> fall into this category.
>
> Also, being able to run the majority of existing applications unchanged,
> and running some applications that make use of the additional features,
> is not at all mutually exclusive.
>
> Everything that was said about a POSIX layer for Coyotos (or a
> Coyotos-like ngHurd) implies a distinct POSIX environment, which allows
> running existing applications in some kind of jail, pretty much isolated
> from the "native" environment with new applications. This is not
> acceptable IMHO. The Hurd allows running traditional and new
> applications *in the same environment*. This is what makes it attractive
> to me.

Since all applications would be run each in its own jail by default I
do not see anything wrong with that. It's not like the jail should be
static, you can add things to it when you want.

Thanks

Michal