Please, don't lecture me about the Hurd being perfect; it's not.
Trust me, I won't lecture you about that, but I might lecture your
about how unperfect it is.
A friend at the AI lab once gave the following dream as an example
of a well-functioning system:
It all sounds like a Lisp Machi
On Sun, 2005-03-20 at 13:48 +0100, Marco Gerards wrote:
> rafael alfaro <[EMAIL PROTECTED]> writes:
>
> > Hi all! I am from El Salvador (Central America), an electronics
> > undergraduate and I want to collaborate with this project, I want to
> > know if somebody already has written code to imple
Thread moved over to bug-hurd since it's about design and not Debian
GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg
installation translator (one where you copy a .deb into a directory to
install it into the system) cannot be easily written, because Debian
package installation scripts
> *wink* how do you purpose to somehow get some kind of interactive
> input from the user when you do a file-system call?
This is a shortcoming in the design of the Hurd (gasp!).
I think you mean that it is a shortcoming in the design of things that
are not or cannot be interactive, file
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> *wink* how do you purpose to somehow get some kind of interactive
> input from the user when you do a file-system call?
This is a shortcoming in the design of the Hurd (gasp!). What works
is a "user interaction context" widget, passed to servers s
Hi Marco
Your help here is very welcome. You just happen to have called at a bad time
when there is an argument going on. I'm afraid I'm not a programmer but only
a user so I cannot help you very well but someone will come to talk.
Welcome
Maurice
>-Original Message-
>From: rafael alfaro
rafael alfaro <[EMAIL PROTECTED]> writes:
> Hi all! I am from El Salvador (Central America), an electronics
> undergraduate and I want to collaborate with this project, I want to
> know if somebody already has written code to implement NAT, if it is not
> thus, I want to do this like thesis in my
Keep track of the conversation. You were supposed to be saying
that the Hurd cannot get Debian to agree to /usr->/ for the Hurd,
and you're wrong. Why switch to getting rid of the symlink?
Because *we didn't have shadowfs*. How many times must I explain
the same point?
Bogus, the
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> My sentence was unclear, what I meant was why change from /usr -> /
> (which has been long in use) and then back again to /usr -> / when the
> plan has always been to have that symlink or atleast have a translator
> sitting there. Removing the syml
Why change back? Because it's better that way.
My sentence was unclear, what I meant was why change from /usr -> /
(which has been long in use) and then back again to /usr -> / when the
plan has always been to have that symlink or atleast have a translator
sitting there. Removing the symlink
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>And as I said, we need shadow translators. Once we have them, we
>could create /usr->/ with little fuss.
>
> We already have a read-only (write support is flakey) implementation
> of unionfs. But why change _back_ to /usr -> / when that wa
And as I said, we need shadow translators. Once we have them, we
could create /usr->/ with little fuss.
We already have a read-only (write support is flakey) implementation
of unionfs. But why change _back_ to /usr -> / when that was used for
years?
Let's change this around. What prob
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>It would be easy to change /usr; we would need to have shadow
>translators, make existing packages install (which is trivial with
>the /usr->/ symlink), and so forth.
>
> We don't have a /usr -> / symlink anymore. It is optional, and th
13 matches
Mail list logo
