I was checking old hurd code and I saw that on the glacial age, Hurd
simply used thread_cancel and condition_wait, but on that date a
mysterious migration to hurd_thread_cancel and hurd_condition_wait
happened.
What I really wanna know is why this change were necessary, since this
may help me on
I think he isn't, Mach Exceptions are just another aproach of signals,
they were used on Mach_US and Lites to implement Unix-compatible
signals. The unique 'problem' is that Mach Exceptions handle not only
process but also threads, so, this is a very fundamental difference.
I also dunno why Mach
"I may disagree with what you have to say, but I shall defend, to the
death, your right to say it." - Voltaire
From: "Alfred M. Szmidt" <[EMAIL PROTECTED]>
To: bug-hurd@gnu.org
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], bug-hurd@gnu.org
In-reply-to: <[EMAIL PROTECTED]> (message from Thomas Schwing
It is possible that you is right about that stuff... anyway, I see no
other way to do that on hurd without break the design...
I hope ngHurd people consider that and do not make 'everything is a
file' design. For sound, video, network stuff.
2006/5/6, Esben Stien <[EMAIL PROTECTED]>:
Richar
StowFS doesn't create links, it uses unionfs. The difference of both is
almost simple, since with links you can remove stow and everything will
keep working. With StowFS you need to have stowfs running to get things
working (this "curiously" create a bootstrap problem2006/2/5, Alfred M. Szmidt <[EM
.2006/2/2, Gianluca Guida <[EMAIL PROTECTED]>:
Hi,(CCing to gnu-system-discuss)On 2/2/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:> I was thinking about why we need to merge all packages on the root
> filesystem is this is not a requirement of POSIX. Posix uses PATH to> determi
I was thinking about why we need to merge all packages on the root
filesystem is this is not a requirement of POSIX. Posix uses PATH to
determine where the executable files are, lib directories are setted on
/etc/ld.so.conf, others directiories of packages are not important to
the system at all, on
As I know, those interfaces already exists. So, I didn't understoo your
"we shouldn't add such interfaces to Mach". I do not understand why
someone would like to use IPC if we have an alternative that is faster
than IPC. This is not related to a good or bad IPC, but the use of good
mechanisms.2006/
Bas Wijnen <[EMAIL PROTECTED]> wrote:
Alfred M. Szmidt wrote:> If someone is Hurd newbie and (s)he tries to use fakeroot for> building Debian packages, what do you think that (s)he'll think> about the Hurd?> > What will the newbie think if she/head finds a totally obscure bug> that eats the file-
> >
> > It can be better than one Wiki, but I think that we need a on-line version that
> > the people can read the newest modifications. Because If only a group, or one
> > person, works in this job the manual could turn boring and discourage people to
> > send fixes. I think that we need most
> "Leonardo Pereira" <[EMAIL PROTECTED]> writes:
>
> > I had said that frow Wiki one person can get the texts, confer they and write the
> > others kind of manual. This can be used only to create the new manual, because
> > it's faster, after you ca
I had said that frow Wiki one person can get the texts, confer they and write the
others kind of manual. This can be used only to create the new manual, because it's
faster, after you can get the new manual and update it how do you want.
--
__
Check o
Why do you not do the Hurd Reference Manual in something like a Wiki, it's faster,
It's easy to remodel, it's more simple to update, it's exciting to who will edit. To
do official versions you can put a person to read the updates and rewrite.
--
__
Che
13 matches
Mail list logo
