[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Marcus Brinkmann |
Subject: |
Re: Reliability of RPC services |
Date: |
Thu, 27 Apr 2006 02:17:59 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Wed, 26 Apr 2006 17:13:25 -0600,
"Christopher Nelson" <address@hidden> wrote:
>
>
> > > Obviously, you will then not use the Hurd. Not only for
> > this, but for
> > > a number of other reasons as well.
>
> I would also like to mention, if I'm not going to use the Hurd, who like
> me will? And why? If a few people install it on their desktops, how
> has that empowered anyone over installing Linux or Solaris or Windows
> for that matter? You WANT museums and libraries and universities to
> install it, because then you have empowered a great many people. Not
> just the few technocratic elite that understand why it's so good.
Why have I empowered a great many people if they are as restricted on
the new system as they were on the old system, because the system
administrators feel that they want to apply the same old policies?
Although it may have sounded differently in my previous mail, for the
foreseeable future I see universities, museums and libraries to lock
down public terminals as much as they can get away with. Their
concerns are dominated by fear of a new technology that they can not
understand nor control. I don't see much room for a new operating
system in that area which values user freedom.
Non-standard configurations of the Hurd could of course provide
lockdown mechanisms. There is no way to prevent that, and it may be
that such a configuration would bring certain benefits (more secure,
robust, easier to maintain, etc). However, initially these would be
advantages for the administrator, not for the user. Empowerment is
something different, and easier to achieve at the desktop where the
user already is in control over the machine.
Thanks,
Marcus
- RE: Reliability of RPC services, (continued)
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- Re: Reliability of RPC services, Jesse D. McDonald, 2006/04/26
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/26
- Re: Reliability of RPC services, Jesse D. McDonald, 2006/04/26
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/26
- Re: Reliability of RPC services, Jesse D. McDonald, 2006/04/26
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/27
RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- Re: Reliability of RPC services,
Marcus Brinkmann <=
RE: Reliability of RPC services, Christopher Nelson, 2006/04/27