Hi, On Thu, Nov 20, 2008 at 11:24:42PM +0100, Michal Suchanek wrote: > 2008/11/20 <[EMAIL PROTECTED]> > > On Thu, Nov 13, 2008 at 11:17:29PM +0100, Michal Suchanek wrote:
> > Things are much more complicated in reality; but conceptually, UIDs > > on Hurd can be regarded more or less as directory capabilities, > > giving access to a set of other, more specific capabilities. [...] > > This is what the Hurd is all about, what I like it for: It opens new > > possibilities the users can take advantage of, but without forcing > > them; without throwing the familiar UNIX environment overboard > > entirely. > Yes, the Hurd is based on Mach which implements ports - capabilities > but hides this under the POSIX interface. I'm not sure "hide" is the right word here... It doesn't immediately confront the user with the internals, but direct use of the advances possibilities resulting from them is encouraged. > In my view saying "this is like posix but it's really capabilities, > and you can do this, that and even more now" is much harder for the > users than saying "our system is based on capabilities, and these work > like this". This might sound alluring in theory, but it just doesn't work in practice. The truth is that people are *much* more comfortable with moving to something that looks familiar than to something completely new. Often this is objectively justifiable, as the migration costs can easily outweigh the benefits from the better but less familiar solution. But even in cases where the more radical approch is objectively better in the long run, most people will still prefer the more familiar one. This is simple psychology -- you can't win against that. A short glance at history should convince you that inertia is the strongest ruling force by far in the computer industry. If you want to have *any* chance of people adapting something new, you have to make the barriers as low as realistically possible. > Note that even POSIX has the UNIX permissions, ACLs, and Windows which > are somewhat POSIX-like have ordered ACLs. Still most users will only > want a GUI dialog which allows them to share a file with another user > and are not interested in the internals of the system. These are > important for the software developers and administrators, not users. You are perfectly right: To the average end user, who just clicks around in his GUI, the use or not-use of capabilities is hardly noticable. (Except that all existing software needs to be adapted...) However, this is not really relevant to the Hurd. As I pointed out in another subthread, the Hurd is a volunteer project, and for a large volunteer project ever to become attractive to average end users, it first needs to attract loads of developers. And for developers, switching to a pure capability system is a *huge* barrier. When I'm talking about users here, I don't mean Aunt Tillie. I mean "power users" -- people who are pushing the limits of the system, and can actually contribute to development. It is the kind of users who make heavy use of POSIX features, and thus extremely unlikely to move to something entirely different. > > I think there are some misunderstandings here. Your information > > seems to originate mostly from the l4-hurd list discussions from the > > "Coyotos era"; while you are lacking both the background that lead > > up to it, and insight about what happend when these discussions died > > down... > > > > First of all, you may not be aware that most of the people taking > > part in these discussions, like you, have not been involved in Hurd > > development before, and know very little about the original > > Hurd/Mach design. Neal and Marcus -- the initiators of the original > > Hurd/L4 port -- being the notable exception. > > I think most of the people talking in the discussion were Hurd > developers. There were very few people in fact and I think I was an > exception not being a Hurd hacker. It is interesting that you got this impression -- but it's simply wrong. There were some other Hurd developers who chipped in a few times; but those people who carried the bulk of the debate, aside from Marcus and Neal, were all outsiders/newcomers: some of them contributed a bit to Hurd/L4, but none of them did any major work on the original Hurd. This is something I know for sure. I actually looked through the archives now to make really sure I'm not lying here. > As I see it the problem with Coyotos is more political than technical. > Technically it might be possible to just not use additional feature > present in the kernel but politically it is a problem if a DRM-capable > design is popularized by being used in the Hurd. It's technical as well: Having to omit some of the Coyotos functionality we don't want; requireing stuff Coyotos is not designed for -- we would have to work around the functionality offered by Coyotos, meaning unnecessary complexity... Same story as with Mach. Why not just create something offering exactly the functionality we need? > Still for me the fact that the user tools work in terms of UIDs is > flawed even if there are expanded possibilities how UIDs can be used. > > I personally want as few and as simple concepts as possible to make up > the foundation of the system and the current Hurd does not provide > that for me. The direct integration of user tools with the capability > concept which would supposedly be part of Coyotos would greatly > simplify the system compared to the Hurd. The one defining feature of the Hurd is the fact that it is the GNU kernel, and consequently must support existing GNU (i.e. POSIX) software without any major changes. Anything else may be up for discussion, but this is not. If you really insist on a completely different system, throwing POSIX overboard alltogether, the Hurd is indeed not the right project for you. -antrik-