Re: A simple question

[Bas Wijnen]

Hi,

On Sat, Apr 15, 2006 at 03:42:20AM +0200, address@hidden wrote:
> On Thu, Apr 13, 2006 at 10:27:40AM +0200, Bas Wijnen wrote:
> > > You do not seem to have much understanding of what the (existing)
> > > Hurd has to offer, if you believe a kernel like Linux could do the
> > > same or even come close *without* a complete rewrite.
> > 
> > Seen from a user perspective, it already comes close.  The cool
> > features of the Hurd are not so spectacular that they'll be impossible
> > on Linux.
> 
> Please don't be ridiculous.

I'll look at all your examples from a user perspective:

> With Linux it's possible not only to implement new filesystems in user
> space, but also to change/extend the file system interfaces themself?

User space?  What's that?  I don't care, as long as it works.

> To replace the whole networking stack?

Why would I want to replace something which is working perfectly well?

> To change the way file access and other permissions work?

Permissions?  It's my computer, so I can do what I want with it.

> To set up proxy environments for processes?

Huh?

> To change the signal facility, the way programs are executed, the way
> sockets work, the way priviliges are propagated etc.?

Again, the thing works fine, why do you want to keep changing it?

> In general, to change/extend nearly every aspect of the system
> functionality,

Things should work, they don't have to be changed all the time.  And if
extentions are made, I can install them from my distribution.

> without any admin action,

I _am_ the admin.

> without affecting other users,

What other users?

> and without restarting the system?

I'm used to restarting the system every now and then, and I don't mind.

Of course, all those things are possible in the kernel (except the "without
admin action" and "without restarting the system", but the user really doesn't
care much about those).

Perhaps some of the users of large multi-user servers _do_ care about some of
these features.  However, they're not the ones who decide what the server
runs.  If the admin doesn't install the Hurd, then they're out of luck.

> Just because most people lack imagination to think beyond FUSE (many
> actually even to think that far...), doesn't mean Hurd has nothing more
> to offer.

They lack it now, and they will lack it later.  The features you mention are
all irrelevant for the end user.  Sure, developers can do nice things with
them which help the end user.  But history has shown that developers will hack
around it and do things which are at least close enough for the end user.

> > Right, you need root access to do things with Linux, and you don't
> > need it on Hurd. We consider that a very good thing.  But do you
> > really think the user cares about it?  Only when things go wrong, and
> > his whole computer is taken over because he did things as root, then
> > he cares.  But if that was a real concern, how many people would still
> > use Windows?
> 
> So you are arguing at the same time that Hurd's security features are
> useless as nobody really cares about security,

No, not useless.  But irrelevant for the user.  Personally I think security is
really important.  Shapiro said that developers should be legally liable if
they put a product on the market which is very insecure, when they know there
are better options.  I like that idea.  But that doesn't mean the end user
cares.

> and that ngHurd is more worthwhile because it improves on some security
> aspects?...

Indeed.  But it's an order of magnitude different.  As I said, users _do_ care
if their whole system breaks down.  That's what this new security brings: You
can run third-party untrusted programs without fearing that it will break your
system, *even if you installed buggy software*.  That kind of security is
simply impossible on a system which wasn't designed for it, and there's no way
to hack around it.

"Normal" people don't want to be taught "don't open attachments, because it's
dangerous"[1].  With this system, they don't need to be told that, because it
isn't dangerous.  This is something that makes people trust their computer,
and I think that's worth a lot.  The reason people don't care about security
may have to do with the little trust they have in the machine anyway: "Even if
I don't get a virus, the thing will still break down by itself every now and
then anyway, so why would I care about security?"

Of course I may be wrong about this.  Maybe people really don't care about
security.  But even then, I still think it's good to force it on them, even if
they don't care about it.  So we'll use the other features to make them want
the system, and they'll have the security, too. :-)

[1] On a good system, opening attachments (with a viewer) should not be
dangerous.  The problem is two-fold: There are often bugs in the viewer, and
Windows-users don't see the difference between running a program and opening a
document (because they just click on it).  However, the end result is the
same: clicking on attachments is dangerous.

> Incidentally, "a cool environment for developers" is much more important
> than what "most people think". Because "most people" do not improve a
> system. It's the developers who do. To the average end user, it doesn't
> matter at all what mechanims the core system provides. What matters is
> what they can do with the system in the end. And that depends on how
> well the system helps *developers* to implement functionality.

I'm not so sure about that.  The system must be comfortable enough that
developers want to use it, of course.  But when they use it, and they want to
build something, they will build it.  If major hackery is involved, then so be
it.  This means it takes a bit longer to build it, and maybe in some cases so
much longer that the developer gives up and will do something else instead,
but in most cases the thing will be built.  It would have been nicer
(technically) and perhaps slightly better on a system like the Hurd, but the
only thing the user would see is that it would be ready sooner on the Hurd.
However, due to the ratio between number of people working on Hurd and those
on Linux, even that is not true.

> GNU/Linux didn't become popular because it was a nice system for average
> end users. It became popular because it was a nice system for
> developers. And only subsequently these developers started slowly making
> it useful for end users.

Yes.  But so far, the Hurd on Mach hasn't attracted many of them, even though
it already provides some really nice features.  Improving performance is a
good thing to do, it may lead to more developers joining.  But if you need a
complete rewrite of the low-level system for it (because you change
microkernels), and you know that there are things which are really cool, and
impossible now, but possible with a new microkernel, then I think it's wasted
effort to do that rewrite and not take those features.

> > However, the discussions about the features should be found when
> > searching for these terms, I think.  That's what I said, too. ;-)  But
> > actually, I expect most of the readers to have followed it at the
> > time, so they all know what it's about anyway.
> 
> The one who started this thread obviously wasn't.

Indeed.  That's why I didn't say "you all know about it", but actually gave
some pointers to where to find it.

> It's not terribly helpful to tell people to spend a week reading up list
> archives to learn about some features. You could just as well tell them
> to fuck off because you can't be bothered to answer their questions...

The explanation is really long, and I don't think I could make a clear summary
of them without spending a considerable amount of time in the archives myself.
But the good news is that we're going to write that summary on a wiki page,
which can then be pointed at. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature